使用jsx，开发组件时，发现大量html代码写在js中，非常丑陋而且不好维护。不知道有什么好的解决方案。
没必要, 以前的 js 嵌入 html 的方式影响JS代码的阅读，维护起来也会麻烦。JSX属于一种domain language, 用来动态生成dom， 写view层。本身不是html。所以你不必考虑这样的问题。
有『大量』的时候，是不是考虑拆分为更小的组件来维护哇
人家生下来就是这样的，你却非要把人家拆开。写 React 代码思维如果不能转过去会悲剧的。
React 有组件这么一说，你还要用以前的框架的思想去编程，是不对的。
JSX 是为了让你写的更爽。
看到有人说 react-template，你看看是不是符合你的需求。
Facebook 注意到了有一群写 CoffeeScript 的人死活不要写奇奇怪怪的语法,
实际上也做了一些让步, 我在 Teambition 用的写法就是 CoffeeScript 版本, 可以参考下:
https://github.com/teambition/react-lite-dropdown/blob/gh-pages/src/dr...
http://facebook.github.io/react/blog/2015/01/27/react-v0.13.0-beta-1.h...
如果你觉得好看的话, 就来吧. 不好看的话估计事情就是这样, 没有太多改变的余地了.
好吧终于认出楼主了.. 补几句..
我试了一下用 Babel 去写, Sublime Text 用 Babel 的插件, 感觉还行.
如果能接纳原生 js 语法的话, 我想还是尝试适应 JSX 的写法更好.
Babel 用的是 ES6, 兼容 JSX, 跟 CoffeeScript 一样也是编译.
现在也遇到了这个问题，头大...
解决方案：在FIS中有__inline()这个方法，如果整个方案是用FIS打包，那么问题很好解决
在render的时候这样调用：
render(__inline(xxx.dom))
为什么可以这样呢？FIS对每个文件都有一个process的操作，在对文件进行编译的时候，在babel将其转化之前，__inline已经将dom内置了，后面babel再对文件进行react jsx转化。
问题是！
FIS采用的是component的组件模式，很多组件其实是基于npm包的二次封装，感觉规范还是有点乱，除非在团队中自己封装所需组件，自己定规范。而且components项目已经不维护了，作者提倡使用npm包代替，毕竟现在的趋势是前后端同构，在React中对于后端渲染也相当有用。
FIS可以按需编译，当时感觉在开发基于React和Redux这种需要n个依赖包的项目编译会越来越慢，也有可能是我某些使用方法不对... 总之没有webpack的热替换好用
基于这两点，我暂时投奔了webpack, 那么问题来了
在webpack中，暂时没有找到这个问题的解决方法，参试使用过raw-loader, xxx-template-loader等类似加载器，但感觉方向是错的...
原因是：webpack这种loader的方式是对于特性的文件，比如test:'/.js$/', 只针对js, 然而raw-loader这种可以将独立出来的jsx代码（比如xxx.html）转换为string, 在js文件中render(string)就会报错。
如果用babel-loader来转换dom, require到js文件里，然后render(variable)，这个方案是可行的，我们可以将module.export = function(content){return "module.export=content}"} 封装到一个loader,在babel前加载
但是这种抽象只能满足content中没有自定义组件的情况，一旦content中的jsx包含自定义组件如<MyComponent>，Babel编译就会报错，所以显然难以抽象出一个loader
个人觉得解决思路应该是做一个js的loader, 对js中的dom文件引入做替换，然后再进行其他loader，比如：
loader: 'babel!inline-dom'
所以inline-dom这个loader是作用域js，而不是作用域dom文件本身，这涉及到一个编译顺序问题。
总之，webpack怎么解决这个问题呢？求高人指点！
一个解决方案就是，不用JSX，手写 React.createElement 函数调用，过一阵子你就会觉得，还是写JSX好。