Redux 专门用于管理状态
Redux 官方文档对 Redux 的定义如下：
一个面向 JavaScript 应用的可预测状态容器。
你可能会问，“如果 React 已经在为我的应用管理前端状态，为何还需要 Redux？”
使用 Redux 的主要优势之一是它可以帮你处理应用的共享状态。如果两个组件需要访问同一状态，该怎么办？这种两个组件同时需要访问同一状态的现象称为“共享状态”。你可以将该状态提升到附近的父组件，但是如果该父组件在组件树中向上好几个组件的位置，那么将状态当做属性向下一个一个地传递，这项工作很快就会变得乏味。此外，在该父组件和该子组件之间的组件甚至根本不需要访问该状态！
在构建 web 应用时，Redux 不仅使我们能够以有条理的方式 存储 数据，而且使我们能够在应用的任何位置快速 获取 该数据。只需告诉 Redux 到底哪个组件需要哪个数据，它就会为你处理后续一切工作！
借助 Redux，你可以控制状态改变的时间、原因和方式。
Store：单一数据源
Redux 的基本原则之一是存在单一数据源：Store。也就是说，Store 包括应用的全局状态，全存储在一个对象树中。
只有单个状态树，对于应用的很多方面都有好处。假设在构建应用时尝试实现撤消/重做功能。如果所有状态都存储在一个树（单一数据源）中，则实现起来比数据分散在多个组件中简单多了。状态集中到一个位置后，调试和检测过程也会简单很多！
为了保持这种单一数据源特性，Redux 制定了几条规则，确保一切尽在掌控。规则一：Redux 应用中的状态是只读的，即 Redux 状态 不可变。例如，React 组件不能直接写入 Redux 状态，而是发出 intent 来更新状态。
实际上，只有叫做reducer的纯函数能够更改状态。暂时别担心这些概念，我们会在下节课深入讲解的！
随着单页面应用变得越来越复杂，正确地管理状态这一需求更加重要。例如，除了管理表格状态（例如《React 基础知识》课程中的 Contacts 应用）等数据外，应用可能还需要管理：
- 服务器响应
- 缓存的数据（例如用户）
- 尚未保存到服务器上的本地数据
除此之外，UI 状态也越来越复杂。同一应用可能还需要跟踪：
- 当前路由
- 当前选择的标签页
- 页码控件
Redux 便因此而生，它专门用于管理上述所有这些内容。创建者 Dan Abramov 在 2015 年根据 Flux 架构创建了 Redux，并从 Elm 编程语言中汲取了经验。从那以后，Redux 变得越来越受欢迎，每月的下载量达到数百万。
总结
Redux 是一个 JavaScript 库，用于管理应用的前端状态。Redux 并非 React 应用的必须条件，但是随着网络应用的复杂性越来越高，状态管理不当可能会导致 bug。Redux 应用中的全局状态存储在单一数据源 store 中。因为状态的更新受到严格控制，使得 Redux 非常具有可预测性。实际上，开发人员喜欢 Redux 的主要原因之一就是它的可预测性。我们来看看背后的原因！
更多资料
- Redux 文档中的 动机 / 英 部分
- Redux 的三大原则 / 英
- GitHub 上的 Redux
- npm 上的 Redux
