标签：default tool 执行 最佳实践 模型 fse patch 设计 模式
本文介绍一下自己在使用React和Redux过程中的一些思考，主要面向初学者。
传统前端开发中，把模板和功能逻辑分开作为一种最佳实践，React采用了不同的思路，通过组件把模板和逻辑组合在一起。但是React也并不是一个完整的组件化框架，其组件化只是主要集中在展示层面，如果要构建复杂的应用，在React component中放置太多的逻辑代码，不仅组件化的初衷复用性会降低，从代码维护的角度看也不合理。
Flux是Facebook提出的一种前端架构模式，通过Flux的数据流模型可以非常优雅地处理应用中的数据流动，配合其他中间件使用可以处理复杂应用中的逻辑行为，从而提高代码的复用性和维护性。其中Redux是所有Flux具体实现中的一个佼佼者。
这里说一下在react、redux开发中可能会用到的一些方便开发的工具和值得研究的第三方库。
react-redux通过Provider和connect两个接口简化了react component与redux的绑定，几乎是必用的一个库。
可以使用chrome的Redux DevTools插件，redux devtools功能非常强大，可以查看store state和action的内容，而且是可以查看所有阶段的store中的数据，甚至撤销或者重新执行action，站在绝对的上帝视角，可以帮助我们快速定位逻辑上的问题。
react-addons-perf是一个性能分析工具，可以打印react component的渲染时间，还可以分析组件渲染过程中浪费的时间，即执行了render方法，而没有在dom上更新的地方，从而发现component中可以优化的环节。
react-addons-update可以方便地创建不可变数据。我们知道为了性能优化中会使用shouldComponentUpdate方法来避免render无意义调用，但是shouldComponentUpdate本身的执行也不能过于复杂，否则反而是增加了执行时间，所以shouldComponentUpdate在对比oldprops和nextprops时一般使用浅对比（shallow compare）。这时如果是对可变对象进行浅比较，结果自然是不准确的，因此需要使用不可变对象，react-addons-update正可以满足这种需求。
可以在console中输出每一个action dispatch后state的变化，是代码调试的好帮手。
通过使用generator可以优雅地处理异步过程，并且可测试性强。
网上已经有很多react性能优化的文章，个人觉得性能优化本身是一个博弈的过程，在代码可读性、维护性与运行性能之间的博弈，很多时候性能优化牺牲了代码的可读性，因此要在合适的时间，在需求基本完成时再进行优化，并且优化中要着眼于性能的瓶颈，没有必要深挖每一个细节，破坏代码本身可读性。
其实React的出现本身就一个博弈的结果，模板和逻辑的分离还是组合的一个博弈结果，React采用组件的方式把传统开发中的模板和逻辑放置在了一起。在选用React之前需要考虑下是否适合采用React。
shouldComponentUpdate的加入是为了避免render方法的无效重复执行，但是如果shouldComponentUpdate函数本身会执行比较复杂的对比，那么加入shouldComponentUpdate得不偿失.
在react中加入redux之后，会尽量设计"纯"component （即对于传入一定 props一定可以输出确定的结果），组件间、甚至组件内部的状态变化都要通过action来实现。但有时使用组件内部的state反而是一种最简便快捷的方式。
组件拆分并不是颗粒越小越好，找到一个可以被复用的平衡点即可，拆分过细反而增加了代码的复杂度。
Facebook最近开源了litho，其设计思路与react如出一辙。对于Android开发者来说，也是一个颠覆性的创新。同时litho提到的异步布局、View复用对于开发者来说也具有很大的吸引力。
分针网—每日分享：说一说 React 和 Redux 你知道或者不知道的一些事情
标签：default tool 执行 最佳实践 模型 fse patch 设计 模式
原文地址：http://www.cnblogs.com/hai1314/p/6829084.html
