在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()方法中完成的。