在Flux架构中，您如何管理商店生命周期？

Question

我正在阅读有关Flux的信息，但示例Todo应用程序对于我来说太简单了，无法理解一些关键点。

想象一下像Facebook这样的具有 用户个人资料页
的单页应用程序。在每个用户个人资料页面上，我们要无限滚动地显示一些用户信息及其最新帖子。我们可以从一个用户个人资料导航到另一个。

在Flux体系结构中，这将与商店和调度员相对应吗？

我们会为PostStore每个用户使用一个，还是会有某种全球商店？调度程序呢，我们将为每个“用户页面”创建一个新的调度程序，还是使用单例？最后，体系结构的哪一部分负责管理“特定于页面的”商店的生命周期以响应路线更改？

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

Answer 1

在Flux应用程序中，应该只有一个Dispatcher。所有数据都流经该中央集线器。拥有单例分派器可以使其管理所有商店。当您需要商店1更新自身，然后根据操作和商店1的状态更新商店2时，这一点就变得很重要。Flux假定这种情况在大型应用程序中是偶然的。理想情况下，这种情况将不需要发生，并且开发人员应尽可能避免这种复杂性。但是，当时间到时，单例分派器已准备好处理它。

商店也是单身人士。它们应保持尽可能独立和分离-一个独立的Universe，可以从Controller-
View查询。进入商店的唯一途径是通过向分派器注册的回调。唯一的出路是通过getter函数。商店在状态改变时也会发布事件，因此Controller-
Views可以知道何时使用getter查询新状态。

在您的示例应用中，会有一个PostStore。该商店可以在“页面”（伪页面）上管理帖子，该页面更类似于FB的Newsfeed，其中帖子来自不同的用户。它的逻辑域是帖子列表，它可以处理任何帖子列表。当我们从伪页面移动到伪页面时，我们想重新初始化存储的状态以反映新状态。我们可能还希望将先前的状态缓存在localStorage中，作为在伪页面之间来回移动的优化，但是我的意愿是设置一个PageStore等待所有其他存储的，管理与所有存储上的localStorage的关系的存储。伪页面，然后更新其自身的状态。请注意，这PageStore将不存储任何帖子-
这是PostStore。因为伪页面是它的域，所以它只会知道特定的伪页面是否已被缓存。

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

如果某个特定的伪页面不需要应用程序中的所有商店，那么我不完全确定除了内存限制之外，还有什么理由可以销毁那些未使用的页面。但是商店通常不会消耗大量内存。您只需要确保在要销毁的Controller-
View中删除事件侦听器即可。这是在React的componentWillUnmount()方法中完成的。