前端之路——Redux(01)

理解Redux

官方文档是这样说的：

Redux is a predictable state container for JavaScript apps

翻译过来就是 Redux 是一个 JavaScript 应用的可预测的状态管理器。

那么，什么是状态？

状态是什么

这里用一个简单的例子来说明。
台灯我们都知道，它包含灯泡，开关。

• 打开开关，灯泡就会亮
• 关闭开关，灯就会灭

在这里，灯泡的亮和灭就是台灯的状态。

一个 JavaScript 应用，从本质上来讲，就是一个能够响应用户操作的东西，台灯也是。用稍显专业的说法，就是一个系统。台灯与开关构成了一个简单的系统。

在 JavaScript 应用中，每当用户进行了一个操作，这个应用都会给予反馈。

• 可以是展示一个动画
• 可以是打开新的页面
• 可以是请求一个列表
• ...

这时，我们就说这个应用的状态发生了变化。

为什么要Redux

要回答这个问题，我们需要先知道Redux是什么。

Redux是什么

本文开头就引用了官方文档中对Redux的概括——一个 JavaScript 应用的可预测的状态管理器。在理解了状态之后，我们大概猜测到，Redux就是管理 JavaScript 应用的状态的工具，当与用户进行交互的时候，可以对状态进行修改。

同样，对照到台灯与开关这个系统，Redux是这样的：

• 打开开关，Redux把台灯的状态变成亮
• 关闭开关，Redux把台灯的状态变成灭

也就是说，JavaScript 应用在完成后有一个初始状态，这时候没有跟用户交互——生下来就是这副模样，接下来的生命周期里，状态变化都由Redux来管理。

Redux的优点是什么

为什么要用Redux，就是要说明Redux解决的问题是什么。
还是台灯。
只有一个开关，一个台灯，这是一个很简单的系统，完全不需要用到Redux也没有问题。
但是如果有十个开关，一个台灯。有一种开关是按一下开，再按一下就关，再按一下又开......按着按着，我们就不能清楚地知道接下来按下一个开关，是不是能关闭台灯了。
在 JavaScript 应用中，如果又多个页面与同一个状态相关，而且这些页面又可以独立变化，那么就很难跟踪这个状态。Redux就是为了解决这个问题。

Redux是通过坚持以下三个原则来实现这一点的：

• 全局只有一个状态中心
  只有一个状态中心意味着所有需要用到这个状态的地方，都直接从这里获取状态，不需要自己再保存一个状态，省去了同步状态的过程。
• 状态是只读的
  只读意味着拿到什么就去渲染什么，这就避免了无意中修改状态导致的问题。想要修改状态，只能使用状态中心提供的方法。
• 只能通过纯函数来修改状态
  修改状态的方法由状态中心提供的纯函数——纯函数可以重复执行，同样的参数就会返回同样的结果。这就保证了对状态的修改是可跟踪的，这也是为什么Redux是可预测的。只能通过指定的方法修改状态，状态的变化只跟输入相关。因此，一旦确定了输入和修改方法，那么状态的结果就是可预测的了。