啥时候用Redux
一个小迭代结束之后，我们前端做了一个几次code revew，其中有个问题就是什么时候应该redux，因为redux其实有些重，但是某些场景其实很简单当让组件也很简单，有观点觉得没有必要上redux。
这个问题需要有个解法。
我觉得需要根据现有的环境来几个方面来考虑。
- 现在我们产品前端组件类别：基础组件、业务通用组件、定制化组件。
- 产品的体量，我们产品是ToB产品，功能比较多，代码量比较大。
- 业务场景的复杂度，因为是ToB，所以场景覆盖比较全，同时定制化需求稍微比较多，所以复杂度比较高。
好，接着我们再看看Redux，要讨论是否需要用它或者什么时候用它我们得搞清楚它的作用是什么。
首先咱们得确定一点React本身其实就是一个UI(View)层它不是一个前端框架， 如果是个复杂的产品，前端光负责View很显然是不够的，所以这几年出现了很多前端架构，比如MVVM架构下的Angular就是一套前端框架.
正因为这样，所以FaceBook提出了Flux的架构，就是为了能推出以React为基础的一套前端框架，让React不再孤单.
至于什么是Flux，阮老师说的很清楚： http://www.ruanyifeng.com/blog/2016/01/flux.html
看完之后你会发现，redux其实就是Flux的一种实现，主要解决两个问题：
- 清晰的代码层次结构，让复杂的前端变得更加健壮和易维护（action、dispatch、reducer等）.
- 让React组件之间通信变得更有效率和更方便（通过store能在任何组件访问想要的数据，不管是横向的还是纵向的层级，而不用依次传递经过根本不需要该数据的组件，真正做到按需使用）
所以说到这儿我们可以简单列一下使用Redux的好处
- 大多数情况下可以用reducer友好的把state从组件里分离出来，使组件更加的轻量化也增加了代码可读性.
- Redux的store可以当成缓存使用，并且是全局的，你可以在任何地方使用它，只要不更新state，无论何时何地获取的数据都是一样的，使数据共享变得容易.
- Redux友好的把state统一放到了store里，通过action、dispatch、reducer，让state的变化变得可预测，让数据流变得清晰明朗，易于维护.
- Redux的store让数据的传递变得更有效率，无需依次进行数据传递（哪怕该组件根本不需要这个数据），可以满足需要的时候再获取.
- Redux更有利于公共组件的开发，公共组件无论在哪儿使用，可以通过dispatch触发其行为.
试着回答一下
我觉得除非已经明确的定义某个组件只是一个纯UI类组件，不会存在其它业务逻辑或者行为，那我觉得没有必要用Redux，比如我们产品中的一些展示组件，这些组件一个最大的特点就是，只需要给它数据，它渲染就完事了不会有额外的一些操作,那完全就一个jsx就搞定了.除此以外都建议用Redux，虽然它复杂了些，但是你会慢慢发现他的好.