Redux 是一种让开发者的工作更为轻松的工具
-
获取并存储数据
-
将数据分配给 UI 元素
-
改变数据
首先，我们需要从云端服务器拉取这些数据并将其保存起来。接下来需要实际显示数据。我们需要将数据拆分开，然后分配给与之对应的 UI 元素，这些 UI 元素正是我们在浏览器中实际所见的。例如，我们将头像照片的 URL 分配给 img标签的 src 属性:
<img src='https://url/to/profile_photo'>最后，我们需要处理数据的变更。例如，如果用户为作品添加了一条评论或点赞，我们需要更新相对应的 HTML 元素。
在前端开发过程中，整合这三类状态是一项大工程，React 对此有着不同程度的支持。有些时候，React 内置的功能就能很好的完成任务。但随着应用变得愈发复杂，单单依靠 React 进行状态管理会变得如履薄冰。这正是许多人开始使用 Redux 的初衷。
获取并存储数据
在 React 中，我们将 UI 拆分成组件。每个组件又可以拆分成更小的组件。(
简单方式就是在需要的时候才去获取数据并将其储存起来。这样就好比每个大厨都驱车前往郊外的农场来采购蔬菜和肉类。
使用 Redux ，我们只获取数据一次，并将数据存储在一个中心区域，通常称之为 “store” 。这样数据对于任何组件来说都可以随时使用。这就像附近有一家超市，我们的大厨们可以在那里买到所有食材。超市会派卡车去农场大批量地运回蔬菜和肉类。这比每个大厨都亲自去农场采购要有效率得多!
store 还是唯一的数据源。组件通常从 store 中获取数据，而不是其他地方。这使得 UI 保持高度统一。
如何将数据传递给实际负责渲染 HTML 元素的组件？将数据从外层组件传递给内层组件就好比是接力赛中的接力棒，一层层地传递下去直到抵达目的地。
改变数据
有时候，在应用中更新数据的逻辑可能会相当复杂。它可能涉及到多个相互依赖的步骤。在更新应用的状态之前，我们可能需要等待多个服务器的响应。我们还可能需要根据不同条件、在多个事件点更新状态内的多处数据。
如果我们没有一个好的结构来实现所有这些逻辑，那将是毁灭性的，代码将难以理解与维护。
Redux 可以让我们进行分治。它提供了一种标准方式来将数据更新逻辑拆分成众多小块的 “reducers” 。这些 reducers 可以在一起协调工作，以完成复杂的动作。
Redux 的真正威力
Redux 强制开发者遵循几个原则，正是这些原则为 Redux 带来了强大的功能(这正是约束的力量！):
-
所有数据(应用的状态)都必须能够以文本的形式进行描述。你需要达到这种程度，用笔在纸上将所有的数据写出来。(译者注: 这里的数据应该指数据结构和数据类型两方面)
-
每个动作(改变数据的操作)都必须能够以文本的形式进行描述。你必须在改变数据之前将其写出来。没有动作就无法改变数据。在 Redux 的术语中这称之为 “派发 (dispatching) 动作”。
-
改变数据的代码必须能够像数学公式一样运行。给定相同的输入，必须返回同样的结果。无论计算多少次，4 的平方永远都是 16 。
当你遵循上述原则来开发应用的话，不可思议的事情就来了。Redux 将开启许多很酷的特性，这些特性使用其他技术很难实现，或者实现起来成本很高。下面是一些例子。
撤消、重做
流行的撤消/重做功能需要系统级的规划。因为撤消/重做需要记录并回放应用中发生的每次数据变化，必须从一开始就在架构层面中考虑它。如果是事后才做，就需要修改大量的文件，这将导致层出不穷的 bugs。
协作环境
Redux 使得通过网络来发送当前用户正在做的事变得很简单。接收到另一个用户在另一台机器上执行的操作后，重放另一个用户所做的更改，并与本地正在发生的动作合并起来是很容易的。
Optimistic UI
Optimistic UI 是一种提升应用用户体验的方式。它可以使得运行在慢网速上的应用也能快速响应用户的操作。在需要实时响应的应用中，这是一种流行的策略，例如第一人称射击游戏。
状态持久化和初始状态加载
Redux 使得将应用中发生的一切纪录并保存下来变得非常简单。就算后面电脑重启，应用也能够轻松加载所有数据，并从完全相同的位置继续运行，就好像它从来没有被中断过一样。
真正可扩展的系统
使用 Redux ，你必须 “dispatch” 动作才能更新应用中的数据。这一限制使得我们几乎可以将应用中发生的一切都联系起来。
你可以构建真正可扩展的应用，其中每个功能都可以由用户来自定义。例如，参考 Hyper ，这是一个使用 Redux 开发的终端应用。“hyperpower” 插件增加了光标的闪光点，并可以使窗口抖动。你是否喜欢这种 “wow” 模式呢？(或许这功能并没有什么用，但却是足够吸人眼球)
时间旅行调试
当调试应用时能够进行时间旅行会是怎样一种体验？运行应用的过程中，随意倒退或前进几次以找到 bug 发生的确切位置，修复 bug 后重放以确认是否修复。
Redux 让开发者梦想成真。Redux 开发者工具可以使开发者通过拖拽滑动条来操纵应用的进度，就像 Youtube 视频一般。
它是如何工作的呢？还记得 Redux 的三大原则吗？它们正是秘诀所在。
自动反馈 Bug
想象一下，用户发现应用中存在问题并想进行反馈。她煞费苦心地回忆和描述她所做过的一切。然后开发人员尝试去手动执行这些步骤以查看 bug 是否复现。用户的反馈很可能是模糊不清的。开发人员很难找到 bug 出现的原因。
如果是这样呢，当用户点击 “反馈问题” 按钮时，系统会自动地将用户本地的状态发送给开发人员。开发人员随即点击 “重发 bug” 按钮便可查看 bug 究竟是如何产生的。Bug 随即被修复，大家都很开心！
Redux Bug Reporter 就是这样玩的。它的工作原理呢？Redux 的限制条件让一切变成可能。
Redux 的缺点
Redux 的三大原则其实是一把双刃剑。它开启强大功能的同时也不可避免地带来一些副作用。
陡峭的学习曲线
Redux 的学习曲线相当陡峭，需要时间去理解、记忆和熟悉它的模式。如果你完全不会 Redux 和 React ，不推荐你两者同时学习。
“样板” 代码
在大多数情况下，使用 Redux 就意味着要多写很多代码。通常需要编写多个文件才能让一个小功能运行起来。开发者一直都在抱怨使用 Redux 时所编写的“样板”代码。
我也知道，这听起来很矛盾。但我可曾说过 Redux 使用很少量的代码就可以实现这些功能？这就有点类似于使用洗碗机。首先，你得花时间仔细地排列盘子。直到完成洗碗你才感受到洗碗机的好处，它节省了洗碗、清洗餐具等方面的时间。所以需要你来决定这个准备时间是否值得!
性能损耗
Redux 的三大原则会对性能产生一些影响。每当数据发生变化时，它会增加一点性能开销。在绝大多数情况下，这不是什么大问题，性能损耗也不明显。但是，当 store 中有大量数据并且数据变化频率非常高的话(例如用户在移动设备上频繁地打字)，UI 可能会变得卡顿。
加分项: Redux 不只是为 React 而生
一种常见的误解就是 Redux 只是为 React 提供的，如果离开了 React ，Redux 将一无是处。确实，正如我们之前一直所讨论的，Redux 解决了 React 的一些痛点。React 是最最常见的 Redux 用例。
但是事实上，Redux 可以和任何前端框架一起使用，比如 Angular、Ember.js，甚至是 jQuery 或原生 JavaScript 。试试 Google 一下，你会发现 这个、这个、这个，甚至是这个。Redux 的思想可以应用于任何地方 ！
随着你越来越广泛地使用 Redux ，你可以在多种场景下享受它带来的好处，而不仅仅是在 React 应用中。
总结
作为工具，Redux 自身也需要去权衡。它开启强大功能的同时也带来了一些不可避免的缺点。一个开发团队的职责就是进行评估，看如何进行取舍并作出明智的选择。
作为设计师，如果我们能够理解 Redux 的优缺点，我们就能够从设计的角度为此决策作出贡献。举个例子，或许我们设计出的 UI 能够缓解潜在的性能影响？也许我们可以提倡使用撤消/重做功能来替代大量的确认对话框？或许我们可以提倡 optimistic UI ，因为它能够以相对较低的代价来提升用户体验。
理解技术的好处与局限性，并作出相应的设计。