您可以在百度里搜索“深入浅出React和Redux 艾草文学(www.321553.xyz)”查找最新章节！

　　3.1.4 Flux的不足

　　任何工具不可能只有优点没有缺点，接下来让我们看看Flux的不足之处，只有了解了Flux的不足之处，才能理解为什么会出现Flux的改进框架Redux。

　　1.Store之间依赖关系

　　在Flux的体系中，如果两个Store之间有逻辑依赖关系，就必须用上Dispatcher的waitFor函数。在上面的例子中我们已经使用过waitFor函数，SummaryStore对action类型的处理，依赖于CounterStore已经处理过了。所以，必须要通过waitFor函数告诉Dispatcher，先让CounterStore处理这些action对象，只有CounterStore搞定之后SummaryStore才继续。

　　那么，SummaryStore如何标识CounterStore呢？靠的是register函数的返回值dispatch-Token，而dispatchToken的产生，当然是CounterStore控制的，换句话说，要这样设计：

　　·CounterStore必须要把注册回调函数时产生的dispatchToken公之于众；

　　·SummaryStore必须要在代码里建立对CounterStore的dispatchToken的依赖。

　　虽然Flux这个设计的确解决了Store之间的依赖关系，但是，这样明显的模块之间的依赖，看着还是让人感觉不大舒服，毕竟，最好的依赖管理是根本不让依赖产生。

　　2.难以进行服务器端渲染

　　关于服务器端渲染，我们在后面第12章“同构”中会详细介绍，在这里，我们只需要知道，如果要在服务器端渲染，输出不是一个DOM树，而是一个字符串，准确来说就是一个全是HTML的字符串。

　　在Flux的体系中，有一个全局的Dispatcher，然后每一个Store都是一个全局唯一的对象，这对于浏览器端应用完全没有问题，但是如果放在服务器端，就会有大问题。

　　和一个浏览器网页只服务于一个用户不同，在服务器端要同时接受很多用户的请求，如果每个Store都是全局唯一的对象，那不同请求的状态肯定就乱套了。

　　并不是说Flux不能做服务器端渲染，只是说让Flux做服务器端渲染很困难，实际上，Facebook也说的很清楚，Flux不是设计用作服务器端渲染的，他们也从来没有尝试过把Flux应用于服务器端。

　　3.Store混杂了逻辑和状态

　　Store封装了数据和处理数据的逻辑，用面向对象的思维来看，这是一件好事，毕竟对象就是这样定义的。但是，当我们需要动态替换一个Store的逻辑时，只能把这个Store整体替换掉，那也就无法保持Store中存储的状态。

　　读者可能会问，有什么使用场景是要替换Store呢？

　　在开发模式下，开发人员要不停地对代码进行修改，如果Store在某个状态下引发了bug，如果能在不毁掉状态的情况下替换Store的逻辑，那就最好了，开发人员就可以不断地改进逻辑来验证这个状态下bug是否被修复了。

　　还有一些应用，在生产环境下就要根据用户属性来动态加载不同的模块，而且动态加载模块还希望不要网页重新加载，这时候也希望能够在不修改应用状态的前提下重新加载应用逻辑，这就是热加载（Hot Load），在第12章会详细介绍如何实现热加载。

　　可能读者觉得这里所说的“偷梁换柱”一样的替换应用逻辑是不可能做到的。实际上，真的能够做到，Redux就能做到，所以让我们进入Redux的世界吧。 深入浅出React和Redux