从设计的角度看Redux

到目前为止，Redux 看上去只是 React 的辅助工具。开发者使用它来解决 React 的某些痛点。但 React 正在快速着手解决这些问题！事实上，Redux 的作者 Dan Abramov 在几年前已经加盟 Facebook 的 React 核心团队。他们一直致力于提升 React 的开发体验: context API (16.3版本发布)、更好的数据获取 API (详情请见 Dan Abramov 于2018年2月的演讲)、更好的 setState API，等等。

它会使 Redux 过时吗？

你猜怎么着？ 我还没有向你展示Redux的真正力量！

Redux 迫使开发人员遵循一些严格的规则，这给 Redux 带来了强大的功能。

1.  所有数据（应用程序状态）必须以明文形式描述。 你应该能够用笔在纸上写下所有数据。
2.  每一个动作(数据的变更)都必须用清晰的文字来描述。你必须把你要做的事写下来，然后再做改变。你不能改变数据而不留下痕迹。在 Redux 的术语中这称之为 “派发 (dispatching) 动作”。
3.  更改数据的代码必须像数学公式一样。 在相同输入的情况下，它必须返回相同的结果。 无论你运行多少次，4 的平方总是 16。

当你遵循上述原则来开发应用的话，不可思议的事情就来了。Redux 将开启许多很酷的特性，这些特性使用其他技术很难实现，或者实现起来成本很高。下面是一些例子。

我从 Dan Abramov 文章 “You Might Not Need Redux” 和 “React Beginner Question Thread.” 中收集了一些示例。

撤销、重做

流行的 撤销/重做 功能需要系统级规划。因为撤销/重做需要记录和回放应用程序中的每一次数据更改，所以你必须从一开始就在架构中考虑到这一点。如果是事后才想到的，那就需要修改很多文件，这是无数错误的根源。

正因为 Redux 需要每个动作都以文本的形式进行描述，所以可以说是天生就支持撤消/重做。这个文档中介绍了如何使用 Redux 来实现撤消/重做。

协作环境

如果你要构建类似于 Google Docs 的应用，其中多个用户在复杂任务上协同工作，请考虑使用 Redux。 它能够为你完成大量繁重的工作。。

Redux 可以非常轻松地通过网络发送正在发生的事情。 接收另一个用户在另一台机器上执行的操作，重放更改并与本地发生的操作合并是很简单的。

OPTIMISTIC UI

Optimistic UI 是 Meteor 提出来的一种前端界面快速响应用户交互的概念，之前叫 Latency Compensation，主要作用是在客户端直接响应用户的交互，而不用等信息从客户端发送到服务器，完成更新确认，再从服务器返回客户端这一个来回完成后再做响应。有点类似游戏领域里的 Dead Reckoning，在客户端离线对用户行为进行推测，达到隐藏延时和减少带宽使用的技术。

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!