从设计的角度看 Redux

阿里云最近在作活动，低至2折，有兴趣能够看看：
https://promotion.aliyun.com/...

---

为了保证的可读性，本文采用意译而非直译。

你知道 Redux 真正的做用远不止状态管理吗？ 你是否想要了解 Redux 的工做原理？ 让咱们深刻研究 Redux 能够作什么，它为何作它的事情，它的缺点是什么，以及它与设计有哪些关联？

你据说过 Redux 吗?它是什么? 请不要用 Google 搜索

• 花哨的后端的东西
• 我据说过它，但我不知道它是什么，这多是一个 React 框架
• 是一种在 React 应用中存储管理状态的更好方式

这个问题，我问过 40 多位设计师，以上是他们的经典回答。他们中的许多人都知道 Redux 与React 一块儿工做，它的工做是状态管理。

本文的目的就是让你对 Redux 有更全面的认知: 它能作什么？为何它要这样设计？什么时候使用它？以及它与设计有哪些关联？

个人目标是帮助像大家这样的设计师。即便您之前没有写过一行代码，我认为理解 Redux仍然是可能的、有益的和有趣的。

什么是 Redux

在超高水平上，Redux 是开发人员用来简化他们工做的工具。大家不少人可能都据说过，它的工做是状态管理。稍后我将解释状态管理的含义， 此刻，我只能想让你看下面这张图:

为何要了解 Redux

Redux 更多的是关于应用程序的内部工做而不是它的外观和感觉。 这是一个有点复杂的工具，学习曲线相对陡峭，但这是否意味着咱们做为设计师应该远离它？

不。我认为咱们应该拥抱它。汽车设计师应该了解引擎的用途，对吗?为了成功地设计应用程序界面，设计师还应该对底层的东西有扎实的了解。咱们应该了解它能够作什么，理解开发人员为何使用它，并了解它的优点和含义。

Redux 能够作什么

开发人员在 React 应用中使用 Redux 来管理状态。这最多见的用法，Redux 改进了React(还没有)作得很差的方面。

然而，你很快就会发现 Redux 的真正功能远远不止于此，让咱们从了解状态管理的真正含义开始。

状态管理

若是你不肯定这个状态意味着什么，让咱们用一个更通用的术语来替换它:数据。状态是不断变化的数据，状态决定在用户界面上显示什么。

状态管理是什么意思? 通常来讲，咱们须要在应用程序中管理三个方面的数据

1. 获取和存储数据
2. 将数据绑定到 UI 元素
3. 改变数据

好比咱们要作一个 Dribbble 的做品页面。在做业页面上咱们想要展现的数据有哪些？其中包括做者的头像照片、名称、动态 GIF 图片、点赞数量、评论，以及等等。

首先，咱们须要从云服务器获取全部这些数据并将其放在某个位置。接下来，咱们须要实际显示数据。咱们须要将这些数据分配给对应的 UI 元素，这些 UI 元素表示咱们在浏览器中实际看到的内容。例如，咱们将头像照片的 URL 分配给 img 标签的 src 属性:

<img src='https://url/to/profile_photo'>

最后，咱们须要处理对数据的更改。例如，若是用户向Dribbble shot添加评论或点赞，咱们须要更新相应的 HTML。

协调状态的这三个方面是前端开发的重要组成部分，React 对这项任务有不一样程度的支持。有时候 React 中的内置功能运行得足够好。但随着应用程序变得愈来愈复杂，仅凭React 可能会更难管理它的状态。这就是为何许多人开始使用Redux做为替代。

获取和存储数据

在React中，咱们将UI分解为组件。这些组件均可以分解为更小的组件。

图片描述

若是咱们的 UI 是这样构造的，那么在填充UI以前，咱们何时获取数据以及在哪里存储数据

假设每一个组件中都有一个厨师。从服务器获取数据就比如是采购所需的全部原材料以准备佳肴。

一种简单的方法是在须要的地方和时间获取和存储数据。这就像每一个厨师直接从遥远的农场购买蔬菜和肉类同样。

这种方法是很浪费的。即便对于相同的数据，咱们也须要从多个组件屡次请求服务器。厨师会浪费大量的汽油和时间来回奔波。

使用Redux，咱们只获取一次数据并将其存储在一个中心位置，称为 store。而后，任何组件均可以随时使用这些数据。这就像附近有一家超市，咱们的厨师能够在那里买到全部的食材。这家超市派卡车从农场大批运回蔬菜和肉类。这比让个别厨师亲自去农场效率高得多。

store 仍是惟一的数据源。组件一般从 store 中获取数据，而不是其余地方。这使得 UI 保持高度统一。

将数据绑定到 UI 元素

若是单单使用 React 的话，实际上有一种更好的方法来获取和存储数据。咱们能够请咱们很是善良的厨师Shotwell为他全部的厨师朋友购物。他会开一辆卡车去农场，把货物运回。咱们能够从容器组件中获取数据，例如 Dribbble 示例中的 Shot 组件，并将其用做单一的数据来源。

这种方法比从每一个组件获取数据的简单方法更有效。可是 Shotwell 是如何将配料传递给其余厨师的呢? 如何将数据传递给实际渲染 HTML 元素的组件? 咱们将数据从外部组件传递到内部组件，就像接力棒同样，一直传递到数据到达目的地。

例如，做者头像的 URL 须要从 Shot 传递到ShotDetail、Title，最后传递到<img> 标签。若是咱们的厨师住在公寓里，它看起来就像这样：

要将数据交付到目的地，咱们必须使用路径上的全部组件，即便它们根本不须要数据。若是有不少层的话，那就太烦人了。

若是超市能送货上门呢? 使用 Redux，咱们能够将任何数据插入任何组件，而不影响其余组件，就像这样

更准确地说，其实是另外一个叫作 react-redux 的库将数据提供给组件的，而并不是 Redux 自己。但由于 react-redux 自己只是个链接库，而且开发者一般一块儿使用 Redux 和 react-redux ，所以我认为将它当作是 Redux 的好处之一是并没有不妥。

注意:在React(16.3)的最新版本中，有一个新的 context API，它的提取数据功能几乎与 Redux 是相同的。所以，若是你的团队使用 Redux 的惟一缘由是为了提取数据，不妨认真考虑升级到 React 16.3!

改变数据

有时候，在应用程序中更新数据的逻辑可能至关复杂。它可能涉及多个相互依赖的步骤。在更新应用程序状态以前，可能须要等待多个服务器的响应。咱们可能须要在不一样的时间、不一样的条件下更新多处 state 的状态。

若是咱们没有一个适合全部逻辑的良好结构，很容易让人使人不知所措，代码也很难理解和维护。

Redux 让咱们分而治之。 它提供了一种将数据更新逻辑分解为小“reducer”的标准方法。 这些 reducer 和谐地协同工做以完成复杂的动做。

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，在客户端离线对用户行为进行推测，达到隐藏延时和减小带宽使用的技术。

举一个简单的例子，在Twitter应用程序中，你的点赞它须要请求服务器进行一些检查，例如，该推文是否仍然存在。 Optimistic UI 的作法不是传统的转圈等待几秒，而后显示结果，而是选择欺骗用户！它事先假定全部请求都是成功的，当用户点赞时直接+1。

这种方式有效的缘由在于大多数时候请求都是正常的。当请求失败是，应用只需回滚至前一个 UI 状态便可，并使用服务器响应的实际结果，例如显示错误信息。

如同撤消/重作同样，Redux 也支持 Optimistic UI。 当从服务器收到否认结果时，能够轻松记录，重放和还原数据更改。

持久化和从状态启动

Redux 能够很容易地将应用程序中发生的事情保存到本地存储中。以后，即便电脑重启，应用程序也能够加载全部数据，并从彻底相同的位置继续运行，就像从未中断过同样。

若是你使用 Redux 构建游戏，则只须要几行代码来保存/加载游戏进度，而无需更改其他代码。

真正可扩展的系统

使用 Redux，你必须“dispatch”一个 action 来更新应用程序中的任何数据。 这种限制使咱们能够深刻了解应用程序中发生的各个方面。

你能够构建真正可扩展的应用，其中每一个功能均可以由用户来自定义。例如，参考 Hyper ，这是一个使用 Redux 开发的终端应用。“hyperpower” 插件增长了光标的闪光点，并可使窗口抖动。你是否喜欢这种 “wow” 模式呢？(或许这功能并无什么用，但倒是足够吸人眼球)

图片描述

时程调试(TIME-TRAVEL DEBUGGING)

当调试应用时可以进行时间旅行会是怎样一种体验？运行应用的过程当中，随意倒退或前进几回以找到 bug 发生的确切位置，修复 bug 后重放以确认是否修复。

Redux 让开发者梦想成真。Redux 开发者工具可使开发者经过拖拽滑动条来操纵应用的进度，就像 Youtube 视频通常。

它是如何工做的？ 还记得 Redux 强制执行的三条严格规则吗？ 这是它的秘诀所在。

图片描述

自动错误报告

想象一下:一个用户在你的应用程序中发现了一些错误，想要报告这个 bug。她煞费苦心地回忆和描述她所作的事情。而后，开发人员尝试手动执行这些步骤，以查看是否再次发生错误。错误报告多是模糊的或不许确的。开发人员很难找到 bug 所在的位置。

如今，这个怎么样。 用户单击“报告错误”按钮。 系统自动将她所作的事情发送给开发人员。 开发人员单击“重播错误”按钮并观察错误是如何发生的。 bug 被当场压扁，每一个人都很开心！

Redux Bug Reporter 就是这样玩的。它的工做原理呢？Redux 的限制条件让一切变成可能。

Redux 的缺点

Redux 执行的三个主要规则是一把双刃剑。它们支持强大的功能，但同时也带来不可避免的缺点。

陡峭的学习曲线

Redux　的学习曲线比较陡峭。 理解，记忆并习惯其模式须要时间。 若是你彻底不会 Redux 和 React ，不推荐你二者同时学习。

　“样板” 代码

在许多状况下，使用Redux意味着编写更多代码。一般须要接触多个文件才能使一个简单的功能正常工做。人们一直在抱怨他们必须用 Redux 编写的样板代码。

我知道，这听起来很矛盾。 我不是说 Redux 可以用最少的代码实现功能吗？ 这有点像使用洗碗机。 首先，你得花时间仔细地排列盘子。 在此以前，你将看到洗碗机的好处：节省实际清洁餐具的时间，消毒餐具等。你必须决定准备时间是否值得！

性能损耗

因为其强制执行的限制，Redux 也可能对性能产生影响。 每当数据发生变化时，它会增长一点开销。 在大多数状况下，这不是什么大问题，并且放缓并不明显。 仍然，当存储中存在大量数据而且当数据频繁改变时（例如，当用户在移动设备上快速键入时），UI 可能所以变得缓慢。

Redux 不仅是为 React 而生

一个常见的误解是 Redux 仅用于 React。 听起来Redux在没有React的状况下没法作任何事情。 事实上，正如咱们以前所讨论的，Redux在几个重要方面补充了React。 React 是最最多见的 Redux 用例。

然而，事实上，Redux可使用任何前端框架，如Angular、Ember.js 甚至jQuery 或者 普通的JavaScript。试着谷歌一下，你会发现这个，这个，这个甚至这个。Redux 的通常思想适用于任何地方

只要你明智地使用 Redux，你能够在不少状况下获得它的好处，而不只仅是在React应用中。

总结

有不可避免的缺点。一个开发团队的职责就是进行评估，看如何进行取舍并做出明智的选择。

做为设计师，若是咱们了解Redux的优点和劣势，咱们将可以从设计的角度为这一决策作出贡献。 例如，咱们是否能够设计用户界面以减轻潜在的性能影响？ 也许咱们能够提倡包含撤消/重作功能来删除大量的确认对话框？ ？或许咱们能够提倡 optimistic UI ，由于它可以以相对较低的代价来提高用户体验。

你的点赞是我持续分享好东西的动力，欢迎点赞！

交流

干货系列文章汇总以下，以为不错点个Star，欢迎 加群 互相学习。

https://github.com/qq44924588...

我是小智，公众号「大迁世界」做者，对前端技术保持学习爱好者。我会常常分享本身所学所看的干货，在进阶的路上，共勉！

关注公众号，后台回复福利，便可看到福利，你懂的。