不只是你，很多人都覺得 Redux 比 Flux 複雜。其實這隻是思想的一個轉換。如果妳學過函數式，你就會感覺到 Reactive Programming 就是應該這樣寫的。
Redux 能讓你的程序只擁有一個 Listener，你不需要在每一個組件中進行一套自己的 state 管理，一切所需的數據都從上游作為 props 傳進來了。
就異步 API 這一塊來說，Flux 的實現其實更加複雜，你需要在每一個 Action Creator 裡進行中間過程的事件管理，而在 Redux 中使用 Middleware ，妳什麼都不用管，直接構造一個描述性的 Action 就可以了。
還有，使用一個 store 並不是激進的做法，反而是簡化了程序的結構。在 Flux 中妳可以給每一個 store 定義一套相互獨立的 API ，所以在大項目中很快就會產生混亂，你的團隊也需要對每一個 store 的接口進行理解才能開始寫。而 Redux 中妳只要設計一個清晰的樹狀數據結構，所有人只要看一眼數據的形狀就能開始寫了。
个人感觉： flux 相比 redux， 类似“分封制” 相比 “郡县制”。
redux不管什么都要从中央走一遍。村里老王家多养只鸡
， 要先汇报中央，
再下发通知给 省 - 市 - 县 - 乡 - 村，所有的一举一动，都被记录在案，随时可追溯。
看起来无比清晰，但是感觉总是有问题的。
这个问题看来没办法根本解决啊，使用immutable配合shouldComponentUpdate，可以使得数据的变动不导致到同级别的组件render，但是父组件肯定要render，假如层级比较深的话，比如会有性能问题了。
根本就不需要手动控制shouldComponentUpdate， connect 已经做了优化，将组件用到的数据，仅用到的数据用 connect 包下会过滤掉不必要的 render。connect 类似白名单这种东西，仅对比用到的 props 数据和相应的 store 数据，有变化则 render
赞同 @suhaotian 所说的，用 connect 生成稍微细粒度一些的 container 就可以解决一部分性能问题。比如针对 list 的情况，大部分时候是对 list 做 container ，但 item 交互比较多，数据经常变的情况下也可以对每个 item 做 container ，充分利用 connect 自带的性能优化。connect 生成的组件自己实现了 shouldComponentUpdate 方法，并且内部是进行 shallow equal 比较的。
一直有个疑问还望指教。container 用 props 一级级的传下去真的好么？为了给最下层的 component 提供一个只有它用到的 state 强行传下去不是非常麻烦且低效吗。所以项目里是用 connect 把 redux 的 state 当 flux 用的，需要用到 store 时直接在 component 上 connect。而 action 为了便于维护，在一般情况下我会放在上层的 “container” 里。希望有人能解答下疑问。
楼主说的不错 当初我一个人看 redux + react + react-router 的时候完全摸不着头脑 现在基本清楚了开发流程
我在 51kanmeiju.com 项目上完全使用了 React + Redux + Webpack 的开发模式 也支持 服务器渲染.
用起来第一个感觉是代码繁琐 增加一个功能要修改不少地方.
我项目地址: https://github.com/51kanmeiju/51kanmeiju
网站在线是 http://51kanmeiju.com/
