状态管理

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

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

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

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

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

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

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

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

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

Dojo 的状态管理

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

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

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