React本身还算简单的，最简单的理解，一个组件渲染函数就是一个基于state和props的纯函数，state是自己的，props是外来的，任何东西变了就重新渲染一边！
跨组件通信，多组件共享状态，多人协作的可维护性，大量嵌套组件的性能问题...等等。这些东西就麻烦了。
Flux/Redux的繁琐，本质上是针对大型应用的复杂度做出的权衡：用繁琐一些的API，换来长线可维护性。在规模不大的应用里，这些问题并不明显，如果使用了这些繁琐的API也就显得有些过度设计了。
Dan Abramov在推特上多次强调，Redux的设计是以几个原则为优先的：要让状态变化可追踪，可复用，可维护。为了达成这个目的，才会有reducer、action、action creator、middleware这些概念。
然而React生态圈里面之前并没有适合中小规模应用的状态解决方案，因为Flux从一开始就是冲着FB scale去设计的，并为考虑中小规模的应用。
react相关面试题：
http://www.jianshu.com/p/940e814a9196
