一个 list，里面一千个 item，然后就慢得无法忍受了，点击一个 item 好几秒以后才有反应。
最后发现元凶是子元素上绑定的 onClick 之类事件，去掉之后速度立马上来了。现在只好用 jQuery 把子元素的事件都委托到了父元素上。
话说这个 EventPluginHub.putListener 到底是啥机制啊……有什么优雅点的解法么……
感觉数据量一上来，react 宣称的性能优势对比与直接 dom 操作就显示不出来了。用 jQuery 的话可以精准地指定更新哪个节点，而用 react 每次必然要全部重新渲染，即使用 shouldComponentUpdate 啥的都优化过了，还是会有很明显的卡顿。
没有直接 dom 操作，类似 TodoMVC 。用 TodoMVC 试了下，也是这样，1000 条 todo，点了三次全选，第一次非常慢，后面的就会好很多了，不知道是什么懒加载机制
然后区别是，TodoMVC 点击单条 todo 是很快的，我这里的项目点击单条也是跟全选一副德行，不知道是哪里姿势不对……
性能问题，最突出的就是父组件的state变化后，子组件无论是否变化都会render。
办法就是，在shouldComponentUpdate进行判断，真正选择哪些需要渲染。
最佳方案就是，Immutable配合React.addons.PureRenderMixin。
通过这样来提升React的性能。
遇到过一次这样的情况，就是在写一个 side by side 功能时，需要 渲染几千行的代码，我是接前面后端同事写的react 代码写的。在给某一行代码添加评论时，要把这个评论给添加到这行代码后面。在前几行代码添加评论还好，如果是给几千行后面的代码添加评论，会卡的不行。我的解决办法就是让评论的添加和评论的编辑和其父组件没有关系（没用到 shouldComponentUpdate 方法）。每行代码都有一个 click 绑定来触发添加评论的事件，并没有卡顿现象。
然后，当渲染代码达到几万行的时候，就不是 react 的问题，而是浏览器的问题，github 几万行代码渲染也只是隐藏不显示。
元素多了，react的dom diff反而降低了性能，比如1000个li，点击某个li，需要给这个li加class=“selected”，react必须要diff 这个1000个li，然后在render。这样的问题在手机h5上更明显，我在h5的上遇到类似的问题，只能减少li的数量，并做shouldComponentUpdate优化。
