5.0 react之redux

我们把Flux看作一个框架理念的话，Redux是Flux的一种实现，除了Redux之外，还有很多实现Flux的框架，比如ReFlux、Fluxible等，但毫无疑问Redux获得得关注度最多，因为Redux具有很多其他框架无法比拟的优势。

Redux是在Flux基础上进行改进的，在所有Flux的变体中算是最受关注的框架，没有之一。

Flux的基本原则是"单向数据流"，Redux在此基础上强调三个基本原则：

• 唯一数据源（Single Source of Truth）;
• 保持状态只读（State is read-only）；
• 数据改变只能通过纯函数来完成（Changes are made with pure functions）

让我们来逐一解释这三条基本原则：

1.唯一数据源

唯一数据源指的是应用的 状态数据 应该只存储在唯一的Store 上。

在Flux中，应用可以拥有多个Store，往往根据功能把应用的状态数据划分给若干个Store分别存储管理。比如，在上面的例子中，我们创造了CounterStore和SummaryStore。

如果状态数据分散在多个Store中，容易造成数据冗余，这样在数据一致性方面容易出现问题。虽然利用Dispatcher的waitFor方法可以保障多个Store之间的更新顺序，但是这又产生了不同Store之间的显示依赖关系，这种依赖关系的存在增加了应用的复杂度，容易带来新的问题。

Redux对这个问题的解决办法是：整个应用只保持一个Store，所有组件的数据源就是这个Store上的状态。

注意：

Redux并没有阻止一个应用拥有多个Store，只是，在Redux的框架下，让一个应用拥有多个 Store 不会带来任何好处，最后还不如使用一个Store更容易组织代码。

这个唯一Store上的状态，是一个树形的对象，每个组件往往只是用树形对象上一部分的数据，而如何设计Store上状态的结构，就是Redux应用的核心问题。

2.保持状态只读

保持状态只读，就是说不能去直接修改状态，要修改Store的状态，必须要通过派发一个 action 对象来完成。这一点和Flux的要求并没有什么区别。

如果只看这个原则的字面意思，可能会让读者感到费解，还记得那个公式吗？UI=render(state)，我们已经说过驱动用户界面更改的是状态，如果状态都是只读的不能修改，怎么可能引起用户界面的变化呢？

当然，要驱动用户界面渲染，就要改变应用的状态，但是改变状态的方法不是去修改状态的值，而是创建一个新的状态对象返回给Redux，由Redux完成新的状态的组装。

这就直接引出了下面的第三个基本原则。

3.数据改变只能通过纯函数完成