I'm reading about Flux but the example Todo app is too simplistic for me to understand some key points.
Imagine a single-page app like Facebook that has user profile pages. On each user profile page, we want to show some user info and their last posts, with infinite scroll. We can navigate from one user profile to another one.
In Flux architecture, how would this correspond to Stores and Dispatchers?
Would we use one PostStore per user, or would we have some kind of a global store? What about dispatchers, would we create a new Dispatcher for each “user page”, or would we use a singleton? Finally, what part of the architecture is responsible for managing the lifecycle of “page-specific” Stores in response to route change?
而且，单个伪页面可能具有相同类型的多个数据列表。例如，个人资料页上，我想同时显示关注和跟随。UserStore在这种情况下，单例如何工作？将UserPageStore管理followedBy: UserStore和follows: UserStore？
在Flux应用程序中，应该只有一个Dispatcher。所有数据都流经该中央集线器。拥有单例分派器可以使其管理所有商店。当您需要商店1更新自身，然后根据操作和商店1的状态让商店2更新自身时，这一点就变得很重要。Flux假定这种情况在大型应用程序中是偶然的。理想情况下，这种情况将不需要发生，并且开发人员应尽可能避免这种复杂性。但是，当时间到时，单例分派器已准备好处理它。
商店也是单身人士。它们应保持尽可能独立和分离-一个可以从Controller-View查询的独立的Universe。进入Store的唯一途径是通过向Dispatcher注册的回调。唯一的出路是通过吸气剂功能。商店还可以在状态更改时发布事件，因此Controller-Views可以知道何时使用getter查询新状态。
在您的示例应用中，会有一个
PostStore。该商店可以在“页面”（伪页面）上管理帖子，该页面更类似于FB的Newsfeed，其中帖子来自不同的用户。它的逻辑域是帖子列表，它可以处理任何帖子列表。当我们从伪页面移到伪页面时，我们想重新初始化存储的状态以反映新状态。我们可能还希望将先前的状态缓存在localStorage中，作为在伪页面之间来回移动的优化，但是我的倾向是设置一个PageStore等待所有其他存储的，管理所有存储上与localStorage的关系的存储。伪页面，然后更新其自己的状态。请注意，这PageStore将不存储任何帖子-这是PostStore。因为伪页面是它的域，所以它只会知道特定的伪页面是否已被缓存。该
PostStore会有一个initialize()方法。即使这是第一次初始化，此方法也始终会清除旧状态，然后根据其通过操作器（通过分派器）接收到的数据来创建状态。从一个伪页面移动到另一个伪页面可能涉及一个PAGE_UPDATE动作，该动作将触发的调用initialize()。关于从本地缓存中检索数据，从服务器中检索数据，乐观渲染和XHR错误状态，有很多细节需要解决，但这是总的思路。如果某个特定的伪页面不需要应用程序中的所有商店，那么我不完全确定除了内存限制之外，还有什么理由可以销毁那些未使用的页面。但是存储通常不会消耗大量内存。您只需要确保在要销毁的Controller-View中删除事件侦听器即可。这是在React的
componentWillUnmount()方法中完成的。