来自 《深入 React 技术栈》

一、单一数据源

传统的 MVC 架构中,需要根据需要创建无数个 Model,而 Model 之间可以互相监听、触发事件甚至循环或嵌套触发事件,这些在 Redux 中都是不允许的。

因为在 Redux 的思想里,一个应用永远只有唯一的数据源,我们的第一反应可能是:如果有一个复杂应用,强制要求唯一的数据源岂不是会产生一个特别庞大的 JavaScript 对象。

实际上,使用单一数据源的好处在于整个应用状态都保存在一个对象中,这样我们随时都可以提取出整个应用的状态进行持久化(比如实现一个针对整个应用的即时保存功能)。此外,这样的设计也为服务端渲染提供了可能。

至于我们担心的数据源对象过于庞大的问题,Redux 也提供了 combineReducers 进行解决。

二、状态只读

Flux 的思想也是如此,但是和 Flux 不同的是,Flux 的 store 没有 setter,因此没法办直接修改应用的状态,而在 Redux 中,这样的限制被执行得更加彻底,因为我们压根没有 store。

在 Redux 中,我们并不会自己用代码定义一个 store,取而代之的是,我们定义一个 reducer,它的功能是根据当前触发的 action 对当前应用的状态(state) 进行迭代,本质上我们没有直接修改应用状态,而是返回一个全新的状态。

Redux 提供的 createStore 方法会根据 reducer 生成 store,最后利用 store.dispatch 达到修改状态的目。

三、修改状态均由纯函数完成

Redux 和 Flux 在表现上最大的不同就是这点。在 Flux 中,我们在 actionCreator 里调用 AppDispatcher.dispatch 方法来触发 action,这样子不仅有冗余的代码,而且应为直接修改了 store 的数据,将导致无法保存每次数据变化前后的状态。

在 Redux 里,我们通过定义 reducer 来确定状态的修改,而每一个 reducer 都是纯函数,这意味着它没有副作用。即接收一定输入,必定会得到一定的输出。

这样的设计好处不仅在于 reducer 里对状态的修改变的简单、纯粹、可测试,更有意思的是,Redux 利用每次新返回的状态生成酷炫的 time travel 调试方式,让跟踪每一次因为触发 action 而改变状态的结果成了可能。