13、Flux架构中的存储与视图管理

Flux架构中的存储与视图管理

1. 存储依赖与复杂性处理

在Flux架构中，为了处理渲染顺序问题，可以引入存储依赖。例如，内容存储虽然不使用头部存储的数据，但为了渲染顺序，它可以依赖头部存储。通过使用 waitFor() 方法，能确保监听头部存储的视图先渲染，避免渲染顺序导致的可用性问题。然而，存储依赖会带来复杂性。当存储依赖过多难以理解时，就需要重新思考存储设计。

Flux存储复杂性的主要原因是依赖管理。尽管有调度器来管理这些依赖，但依赖过多时，会丢失一些信息。当架构中的存储过多时，会导致复杂的情况。随着应用的发展，功能增多会引入更多存储，现有存储也会变得更复杂，因为它们要与应用的其他变化功能协同工作。这会导致依赖爆炸，通用存储也可能成为问题源，可能会出现过多通用存储，使所有状态数据都间接化。当架构中的存储数量难以维持时，就需要重新思考功能的构成。

2. 重新思考功能域

通常，顶级功能映射到存储的方式能正常工作，但当顶级功能过多时，就需要重新评估这种策略。如果有很多顶级功能，可能存在大量相似数据，可以合并到一个存储中驱动多个功能。减少驱动功能的存储数量，还可能消除通用存储。通用存储在有过多重复数据时有用，但存储数量减少时，重复数据问题也会减少。

也可能会遇到存储复杂性过高的情况，这时需要将其重构为多个存储，把一个大功能拆分成两个小功能。如果无法找到好的拆分方法，可能只能维持存储的复杂性。

3. 视图信息传递

视图层是Flux架构中数据流动的最后一站，视图直接向用户提供信息并响应用户交互。视图没有自己的数据源来渲染UI元素，而是依赖Flux存储的状态，并监听状态