状态管理

企业应用程序通常需要持久化状态，并允许用户以各种方式查看和操作这些数据。当需要同时在多处访问和编辑同一数据，且要保持数据的一致性时，状态管理可以成为大型应用程序中最复杂的领域之一。

状态通常存在位于 web 应用程序组件外部的数据存储或数据库中，这意味着一些状态管理复杂性需要在应用程序之外解决。然而，对于数据在应用程序与其用户之间流动的情况，有几个范例能够大大的降低管理复杂状态的风险。

响应式的数据修改

以命令式方式编写的应用程序会描述应更改哪些数据，应该如何更改，以及指定必须在何时何地更改。如果通过某种形式的计算或赋值在逻辑上连接多块数据，则这些连接在一段时间后只能表示成离散的点。久而久之，除了这些点之外，可能会以违反预期逻辑连接的方式修改任何数据值。

相反，以响应式方式编写的应用程序设法提升数据之间的逻辑连接，并放弃对明确地指定何时何地修改数据的控制，以使逻辑数据连接始终保持一致。

具有多个服务层的复杂应用程序可能会在多处描述相同的数据，因为它们散落在应用程序的各处——这方面的一种常见模式是使用数据传输对象。一段数据的描述位置越多，则维护应用程序状态完整性的复杂度呈指数级增长。

任何应用程序只要 UI 需要动态展示（包括 web 应用程序），都会遇到维护逻辑数据连接一致性的问题。这些应用程序中的数据通常至少有两种表示方式。

举例说明问题

假设有一个待办事项应用程序，它存储了一组任务，当向用户显示时，每个任务都有以下两种数据表示方式：

  • 任务的确切描述（它的“真实来源”，例如它在数据存储中的值）
  • 任务描述的副本，通过 UI 元素（如 label 或 textbox）呈现给用户。

如果用户只能查看任务，则有几个问题与如何修改任务的描述以让用户可见有关。

如果在底层的数据存储中更改了任务，则需要通过 UI 向上传播新的描述信息，这样用户就不会查看过时的数据。如果任务显示在 UI 的多个位置，则所有实例都需要更新，确保用户不会在不同位置看到的数据不一致。

如果用户还可以修改任务（比如更改描述信息），则还需要解决其他问题。

任务描述现在有两处真正的来源：数据存储中的旧值，以及用户在 textbox 中输入的新值。

然后，需要将修改请求传回给底层的数据存储，以便用新值替换旧值。修改完成后，需要将新的任务描述返回给用户，让用户看到更改后的正确值。尝试修改任务描述时会发生的任何错误也需要在数据交换时考虑。

Dojo 的状态管理

对于最基本的状态管理需求，部件可以使用本地变量管理自身的状态。虽然这种方法有助于隔离和封装，但它只适用于非常简单的用例，如只在应用程序中出现一次的部件，或者与应用程序处理的所有其他状态都断开了连接的部件。

随着在部件间共享状态的需求增加，Dojo 支持响应式的控制反转。将状态提升到父容器部件中，然后使用子部件的 properties 接口注入到子部件中。如果需要，这种状态提升可以横穿整个部件层级，将状态集中在应用程序根部件中，然后将部分状态注入到相关的子分支中。

对于更复杂的需求，或者对于较深的部件层级且不希望在不相关的中间层传递状态，则外部的数据存储可能是最好的方法。集中的数据存储能够帮助应用程序处理大量的状态，允许复杂的状态编辑操作，或者在多处请求相同的状态子集。

Dojo 提供了一个 Store 组件，它支持多种高级的状态管理需求，例如：

  • 内置支持异步调用，例如调用远程服务进行数据管理。
  • 状态操作按确定的顺序执行。
  • 记录状态操作历史，允许回滚或撤销操作。
  • 中间件用于包装数据操作流程，可添加横切点，如用于授权或记日志。
  • 内置支持基于 LocalStorage 的数据存储，有助于实现 PWA。
  • 支持乐观的数据更新，失败时会自动回滚。