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

　　3.1.3 Flux的优势

　　本章的例子和上一章我们只用React的实现效果一样，但是工作方式有了大变化。

　　回顾一下完全只使用React实现的版本，应用的状态数据只存在于React组件之中，每个组件都要维护驱动自己渲染的状态数据，单个组件的状态还好维护，但是如果多个组件之间的状态有关联，那就麻烦了。比如Counter组件和Summary组件，Summary组件需要维护所有Counter组件计数值的总和，Counter组件和Summary分别维护自己的状态，如何同步Summary和Counter状态就成了问题，React只提供了props方法让组件之间通信，组件之间关系稍微复杂一点，这种方式就显得非常笨拙。

　　Flux的架构下，应用的状态被放在了Store中，React组件只是扮演View的作用，被动根据Store的状态来渲染。在上面的例子中，React组件依然有自己的状态，但是已经完全沦为Store组件的一个映射，而不是主动变化的数据。

　　在完全只用React实现的版本里，用户的交互操作，比如点击“+”按钮，引发的时间处理函数直接通过this.setState改变组件的状态。在Flux的实现版本里，用户的操作引发的是一个“动作”的派发，这个派发的动作会发送给所有的Store对象，引起Store对象的状态改变，而不是直接引发组件的状态改变。因为组件的状态是Store状态的映射，所以改变了Store对象也就触发了React组件对象的状态改变，从而引发了界面的重新渲染。

　　Flux带来了哪些好处呢？最重要的就是“单向数据流”的管理方式。

　　在Flux的理念里，如果要改变界面，必须改变Store中的状态，如果要改变Store中的状态，必须派发一个action对象，这就是规矩。在这个规矩之下，想要追溯一个应用的逻辑就变得非常容易。

　　我们已经讨论过MVC框架的缺点，MVC最大的问题就是无法禁绝View和Model之间的直接对话，对应于MVC中View就是Flux中的View，对应于MVC中的Model的就是Flux中的Store，在Flux中，Store只有get方法，没有set方法，根本可能直接去修改其内部状态，View只能通过get方法获取Store的状态，无法直接去修改状态，如果View想要修改Store状态的话，只有派发一个action对象给Dispatcher。

　　这看起来是一个“限制”，但却是一个很好的“限制”，禁绝了数据流混乱的可能。

　　简单说来，在Flux的体系下，驱动界面改变始于一个动作的派发，别无他法。 深入浅出React和Redux