从设计的角度看Redux

举一个简单的例子，在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 编写的样板代码。

（编辑：源码门户网）

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