javascript - 在 Flux 架构中，你如何管理 Store 生命周期？

Question

我正在阅读 Flux但是example Todo app对我来说太简单了，无法理解一些关键点。

想象一下像 Facebook 这样具有用户个人资料页面 的单页应用。在每个用户个人资料页面上，我们想显示一些用户信息和他们最近的帖子，无限滚动。我们可以从一个用户配置文件导航到另一个用户配置文件。

在 Flux 架构中，这将如何对应 Stores 和 Dispatchers？

我们会为每个用户使用一个 PostStore，还是会拥有某种全局商店？调度器怎么样，我们会为每个“用户页面”创建一个新的调度器，还是我们会使用单例？最后，架构的哪一部分负责管理“页面特定”Store 的生命周期以响应路由更改？

此外，一个伪页面可能有多个相同类型的数据列表。例如，在个人资料页面上，我想同时显示Followers 和Follows。在这种情况下，单例 UserStore 如何工作？ UserPageStore 会管理 followedBy: UserStore 和 follows: UserStore 吗？

Answer 1

在一个 Flux 应用中应该只有一个 Dispatcher。所有数据都流经这个中心枢纽。拥有一个单例 Dispatcher 允许它管理所有商店。当您需要 Store #1 更新自身，然后让 Store #2 根据操作和 Store #1 的状态更新自身时，这一点变得很重要。 Flux 假设这种情况是大型应用程序中的一种可能性。理想情况下，这种情况不需要发生，如果可能的话，开发人员应该努力避免这种复杂性。但单例 Dispatcher 已准备好在时机成熟时处理它。

商店也是单例。它们应该尽可能地保持独立和解耦——一个可以从 Controller View 查询的自包含宇宙。进入 Store 的唯一途径是通过它向 Dispatcher 注册的回调。唯一的出路是通过 getter 函数。 Stores 还会在其状态发生变化时发布事件，因此 Controller-Views 可以知道何时使用 getter 查询新状态。

在您的示例应用程序中，将有一个 PostStore。这家商店可以管理“页面”(伪页面)上的帖子，该页面更像是 FB 的新闻源，其中帖子显示来自不同的用户。它的逻辑域是帖子列表，它可以处理任何帖子列表。当我们从伪页面移动到伪页面时，我们想要重新初始化商店的状态以反射(reflect)新状态。我们可能还想在 localStorage 中缓存先前的状态，作为在伪页面之间来回移动的优化，但我倾向于设置一个等待所有其他存储的 PageStore，管理伪页面上所有商店与 localStorage 的关系，然后更新自己的状态。请注意，此 PageStore 不会存储有关帖子的任何信息——这是 PostStore 的域。它只会知道特定的伪页面是否已被缓存，因为伪页面是它的域。

PostStore 会有一个initialize() 方法。此方法将始终清除旧状态，即使这是第一次初始化，然后根据通过 Dispatcher 通过 Action 接收的数据创建状态。从一个伪页面移动到另一个伪页面可能会涉及 PAGE_UPDATE 操作，这会触发 initialize() 的调用。围绕从本地缓存检索数据、从服务器检索数据、乐观渲染和 XHR 错误状态，还有一些细节需要解决，但这是总体思路。

如果一个特定的伪页面不需要应用程序中的所有商店，除了内存限制之外，我不完全确定是否有任何理由销毁未使用的页面。但是存储通常不会消耗大量内存。您只需要确保删除您正在销毁的 Controller View 中的事件监听器。这是在 React 的 componentWillUnmount() 方法中完成的。