Motivation: What problems does Redux try to solve?">Motivation: What problems does Redux try to solve?">
跳至主要内容

动机

随着 JavaScript 单页应用程序的需求越来越复杂,**我们的代码必须管理比以往更多的状态**。这种状态可以包括服务器响应和缓存数据,以及尚未持久化到服务器的本地创建数据。UI 状态也越来越复杂,因为我们需要管理活动路由、选定的选项卡、加载指示器、分页控件等等。

管理这种不断变化的状态很困难。如果一个模型可以更新另一个模型,那么一个视图可以更新一个模型,这又会更新另一个模型,而这反过来又可能导致另一个视图更新。在某些时候,你不再理解你的应用程序中发生了什么,因为你**失去了对何时、为何以及如何改变其状态的控制**。当一个系统不透明且非确定性时,很难重现错误或添加新功能。

如果这还不够糟糕,请考虑**前端产品开发中越来越常见的新的需求**。作为开发人员,我们被期望处理乐观更新、服务器端渲染、在执行路由转换之前获取数据等等。我们发现自己试图管理以前从未遇到过的复杂性,我们不可避免地会问自己:是时候放弃了吗? 答案是

这种复杂性很难处理,因为我们混合了两个概念,而这两个概念对于人类思维来说很难理解:变异和异步性。我称它们为曼妥思和可乐。两者分开都很棒,但放在一起就会一团糟。像React这样的库试图通过消除异步性和直接 DOM 操作来解决视图层中的这个问题。但是,管理数据的状态就留给你自己了。这就是 Redux 登场的地方。

FluxCQRS事件溯源的步骤中,Redux 试图通过对更新发生的时间和方式施加某些限制来使状态变异变得可预测。这些限制反映在 Redux 的三个原则中。