你知道Redux真的不仅仅是状态管理吗？您想了解Redux的工作原理吗？让我们深入了解Redux可以做什么，为什么它会做它所做的事情，它的缺点是什么，以及它与设计有什么关系？你听说过Redux吗？它是什么？请不要在谷歌上搜索花哨的后端东西我听说过但我不知道它是什么，它可能是一个React框架是一种管理React应用程序中存储的方法我已经问过40多位设计师关于这个问题更好的状态，以上是他们的经典答案。他们中的许多人都知道Redux与React一起工作，它的工作是状态管理。这篇文章的目的是让你更全面地了解Redux：它能做什么？为什么要这样设计？何时使用它它与设计有何关系？我的目标是帮助像您这样的设计师。即使你以前没有写过一行代码，我认为理解Redux仍然是可能的、有益的、有趣的。什么是Redux在超高的层次上，Redux是开发人员用来简化工作的工具。你们中的许多人可能都听说过，它的工作是状态管理。我稍后会解释状态管理的含义，目前，我只能向您展示下图：为什么您应该了解ReduxRedux更多的是关于应用程序的内部运作，而不是它的外观和感觉。这是一个有点复杂的工具，学习曲线相对陡峭，但这是否意味着我们作为设计师应该远离它？不，我认为我们应该接受它。汽车设计师应该了解发动机的用途，对吗？为了成功地设计一个API，设计者还应该对幕后的内容有深入的了解。我们应该理解它能做什么，理解开发者为什么使用它，理解它的优点和含义。Redux可以做什么开发人员使用Redux来管理React应用程序中的状态。最常见的用法是，Redux改进了React（还）做得不好的事情。然而，您很快就会发现Redux远不止于此，让我们从了解什么是状态管理开始吧。状态管理如果你不确定这个状态是什么意思，让我们用一个更通用的术语来代替它：数据。状态是不断变化的数据，状态决定了用户界面上显示的内容。状态管理是什么意思？一般来说，我们需要在应用程序中管理三个方面的数据：获取和存储数据、将数据绑定到UI元素以及更改数据。比如我们要做一个Dribbble工作页面。我们希望在作业页面上显示哪些数据？这包括作者的头像、姓名、动画GIF、点赞数、评论等。首先，我们需要从云服务器获取所有这些数据并将其放在某个地方。接下来，我们需要实际显示数据。我们需要将此数据分配给相应的UI元素，这些元素代表我们在浏览器中实际看到的内容。例如，我们将个人资料照片的URL分配给img标签的src属性：我们需要处理数据的变化。例如，如果用户对Dribbble截图进行了评论或点赞，我们需要更新相应的HTML。协调这三个方面的状态是前端开发的重要内容，React对这项工作有不同程度的支持。有时React中的内置功能可以很好地工作。但是随着应用程序变得越来越复杂，单独使用React管理其状态会变得更加困难。这就是为什么许多人开始使用Redux作为替代方案的原因。获取和存储数据在React中，我们将UI分解为组件。这些组件都可以分解成更小的组件。Imagedescription如果我们的UI是这样结构的，那么我们什么时候获取数据以及在填充UI之前我们将数据存储在哪里假设每个组件中都有一个Chef。从服务器获取数据就像采购准备一顿美餐所需的所有食材。一种简单的方法是在需要的地方和时间获取和存储数据。这就像每个厨师都直接从遥远的农场购买蔬菜和肉类。简单方式：每个组件都去获取自己需要的数据，比较浪费。即使是同一份数据，我们也需要向多个组件多次请求服务器。厨师会浪费大量的汽油和时间来回奔波。使用Redux，我们只获取一次数据并将其存储在称为商店的中央位置。然后任何组件都可以随时使用此数据。这就像附近有一家超市，我们的厨师可以在那里买到所有的食材。超市派卡车从农场运回散装蔬菜和肉类。这比让个别厨师亲自去农场效率高得多。商店也是唯一的数据源。组件通常从商店而不是其他地方获取数据。这使UI保持高度统一。Redux集中存储数据并将数据分配给UI元素将数据绑定到UI元素如果您单独使用React，实际上有更好的方法来获取和存储数据。我们可以请我们非常友善的厨师Shotwell为他所有的厨师朋友购物。他会开卡车到农场，把货物运回来。我们可以从容器组件（例如Dribbble示例中的Shot组件）中获取数据，并将其用作单一数据源。这种方法比从每个组件获取数据的简单方法更有效。但是肖特韦尔是如何将食材传递给其他厨师的呢？它如何将数据传递给实际呈现HTML元素的组件？我们将数据从外部组件传递到内部组件，就像接力棒一样，直到数据到达目的地。例如，作者头像的URL需要从Shot传递到ShotDetail、Title，再传递到![]()
标签。如果我们的厨师住在公寓里，它会是这样的：为了将数据传送到目的地，我们必须使用路径上的所有组件，即使它们根本不需要数据。如果有很多层，这很烦人。如果超市可以送货上门呢？使用Redux，我们可以在不影响其他组件的情况下向任何组件插入任何数据，像这样更准确地说，另一个名为react-redux的库实际上是将数据提供给组件，而不是Redux本身。但由于react-redux本身只是一个连接库，而开发者通常将Redux和react-redux一起使用，所以我认为将其视为Redux的好处之一并没有错。使用Redux直接抽取数据到目标组件注：在React（16.3）版本中，新增了contextAPI，其抽取功能与Redux几乎相同。因此，如果您的团队使用Redux的原因是拉取数据，请认真考虑升级到React16.3！更改数据有时在您的应用程序中更新数据的逻辑可能非常复杂。它可能涉及多个相互依赖的步骤。在更新应用程序状态之前，可能需要等待来自多个服务器的响应。我们可能需要在不同的时间、不同的条件下更新多个状态的状态。如果我们没有一个良好的逻辑结构，很容易不知所措，代码也很难理解和维护。Redux让我们分而治之。它提供了一种将数据更新逻辑分解为小型“reducer”的标准方法。这些减速器协同工作以执行复杂的操作。Redux的真正威力到目前为止，Redux似乎只是React的一个辅助工具。开发者用它来解决React的一些痛点。但是React正在快速解决这些问题！事实上，Redux的作者DanAbramov在几年前就加入了Facebook的React核心团队。他们一直致力于改善React开发体验：上下文API（16.3版）、更好的数据获取API（有关详细信息，请参阅DanAbramov2018年2月的演讲）、更好的setStateAPI等等。它会让Redux过时吗？你猜怎么了？我还没有向你展示Redux的真正力量！Redux迫使开发人员遵循一些严格的规则，这给Redux带来了强大的力量。所有数据（应用程序状态）必须以明文形式描述。您应该能够用笔将所有数据写在纸上。每个动作（数据更改）都必须以明文形式描述。你必须写下你要做什么，然后做出改变。您无法在不留下痕迹的情况下更改数据。在Redux术语中，这称为“调度操作”。更改数据的代码必须像数学公式一样工作。给定相同的输入，它必须返回相同的结果。无论运行多少次，4的平方始终是16。当您按照上述原则开发应用程序时，不可思议的事情就来了。Redux将启用许多很酷的功能，这些功能使用其他技术很难或昂贵地实现。下面是一些例子。我从DanAbramov的文章“YouMightNotNeedRedux”和“ReactBeginnerQuestionThread”中收集了一些示例。撤消、重做流行的撤消/重做功能需要系统级规划。因为撤消/重做需要记录和重放应用程序中的每个数据更改，所以您必须从一开始就在您的体系结构中考虑到这一点。如果是事后诸葛亮，就是要修改一大堆文件，也是无数bug的根源。正因为Redux要求每一个action都以文本的形式描述，所以可以说它天生就支持undo/redo。本文档描述了如何使用Redux实现撤销/重做。协作环境如果您正在构建类似GoogleDocs的应用程序，其中多个用户一起处理复杂任务，请考虑使用Redux。它为您做了很多繁重的工作。.Redux使得通过网络发送正在发生的事情变得非常容易。获取另一个用户在另一台机器上所做的事情、重放更改并与本地发生的事情合并是微不足道的。OPTIMISTICUUIOptimisticUI是Meteor提出的前端界面快速响应用户交互的概念。它以前称为延迟补偿。它的主要功能是在客户端直接响应用户交互，而不用等待客户端向服务器端发送信息完成更新确认，然后从服务端返回给客户端，来回完成后再响应。有点类似于游戏领域的航位推算。它在客户端离线推测用户行为，以隐藏延迟并减少带宽使用。举个简单的例子，在推特应用中，你的点赞需要请求服务器做一些检查，比如这条推文是否还存在。OptimisticUI的做法不是传统的循环等待几秒，然后显示结果，而是选择欺骗用户！它预先假设所有的请求都成功了，当用户点赞的时候直接+1。这样做的原因是大多数时候请求是正常的。当请求失败时，应用程序简单地回滚到之前的UI状态并使用服务器响应的实际结果，例如显示错误消息。与撤销/重做一样，Redux也支持OptimisticUI。当从服务器收到否定结果时，可以轻松记录、重放和恢复数据更改。持久化和从状态启动Redux可以很容易地将应用程序中发生的事情保存到本地存储。之后，即使计算机重新启动，应用程序也可以加载所有数据并从完全相同的位置继续运行，就好像它从未被中断过一样。如果您使用Redux构建游戏，则只需几行代码即可保存/加载游戏进度，而无需更改其余代码。一个真正可扩展的系统使用Redux，您必须在其中“调度”一个操作来更新应用程序中的任何数据。这种限制使我们能够深入了解应用程序中发生的各个方面。您可以构建真正可扩展的应用程序，其中每个功能都可以由用户自定义。例如，请参阅Hyper，这是一个使用Redux开发的终端应用程序。“hyperpower”插件增加了光标的闪烁度并且可以使窗口摇晃。你喜欢这种“哇”的模式吗？（也许这个功能用处不大，但足够吸引眼球了）图为穿越调试（TIME-TRAVELDEBUGGING）在调试应用程序时能够穿越会是一种怎样的体验？在运行该应用程序时，随意来回几次以找到错误发生的确切位置，修复错误，然后重播以查看是否已修复。Redux让开发者梦想成真。Redux开发人员工具允许开发人员通过拖动滑块来操纵应用程序的进度，就像Youtube视频一样。它是如何工作的？还记得Redux强制执行的三个严格规则吗？这是它的秘密。图片描述自动错误报告想象一下：用户在您的应用程序中发现了一些错误并想要报告错误。她不厌其烦地回忆和描述自己的所作所为。然后，开发人员尝试手动执行这些步骤以查看错误是否再次发生。错误报告可能含糊不清或不准确。开发人员很难找出错误所在。现在，这个怎么样。用户单击“报告错误”按钮。系统会自动将她所做的发送给开发人员。开发人员单击“ReplayBug”按钮并观察错误是如何发生的。bug当场被压扁了，大家都很开心！这就是ReduxBugReporter的工作原理。它是如何工作的？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的优点和缺点，我们将能够从设计的角度做出这个决定。例如，我们可以设计用户界面来减轻潜在的性能影响吗？也许我们可以提倡包含撤消/重做功能以删除大量确认对话框？？或许我们可以提倡乐观的UI，因为它可以以相对较低的成本提升用户体验。
