总结 React + Redux: section 1 - Motivation

Redux 是 React's Flux 模式的具体实现，那么为什么facebook 要强调Flux这么个模式呢? 这个问题也等价于： 为什么要在React项目里用 Redux 呢？

为什么要用 Redux？ Redux是干什么的？

以下左图是 Facebook 给出来的传统 MVC模式，看出来有什么弊端了吗？ 右图是 Redux 给出的motivation。

接下来就这两幅对比图来解释下为什么 Redux 比 MVC好。MVC图中Model喝View 直接交互，意思是View直接修改Model的状态（也就是变量），Model也能直接更新View 。随着项目变大，Model喝View的交互关系会越来愈复杂。比如，一个legacy的react项目转交到你的手上，要求你增加新feature。ok，你写好了新的react view，这个view 执行时会更新了某一个model里的状态，好了，run test，你发现你写的view执行后，页面里的其他某些views 在不知原因的也更新起来，好像随机一样。Bug！这不是你期待的。只好一步一步的debug了，发现你更新的那个model会update 其他的views，再跟进，发现其他views又牵扯更多的model状态更新。。。 继续在几百个model 和 几百个react component里跟踪调试吧。。。。

这像不像曾经Mozilla经典的失败开发案例。话说很久以前，apple还没有Safari的时候，要求Mozilla为其开发browser。钱给到位，Mozilla撸起袖子，拿来自家的Netscape浏览器，修修改改，结果发现修改一个model，引发另外几个models 也需要修改，修改了那几个models，发现又有新的models需要修改。。。 然后项目当然是失败了。之后通过对该项目6193 files分析，发现存在mutual dedendency！！！ 

所以对于动辄几千几百个files的项目，很难保证不存在这种mutual依赖。mutual依赖也注定了这将是失败的项目。。。

Redux 的 flux 模式 到底是怎么改进的mvc中 m-v这种杂乱的依赖关系呢？Redux只允许view间接的修改状态（对比mvc的view是直接的修改model），见下图：

 

现在用上了Redux，你写好了一个view，想要去修改某个model，对不起，你不能直接去访问该model。怎么办，去查查Redux的action和reducer有没有对应的修改改model的方法。如果没有。。。 去找老同志问问能不能为了你的这个view去修改/增加reducer或action的功能（这两个东东可以修改model/state）。。。。  整个这个过程下来，你发现你的新view想修改model，有这么多条条框框约束着。。。好处就是某个程序员不能随意赋予view 到 model states之间的依赖关系，造成MVC那样的混乱依赖。