在 Flux 架构中，您如何管理 Store 生命周期? [英] In Flux architecture, how do you manage Store lifecycle?

问题描述

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

I'm reading about Flux but the example Todo app is too simplistic for me to understand some key points.

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

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.

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

In Flux architecture, how would this correspond to Stores and Dispatchers?

我们会为每个用户使用一个 PostStore，还是会拥有某种全球商店?调度器呢，我们会为每个用户页面"创建一个新的调度器，还是使用单例?最后，架构的哪一部分负责管理特定页面"商店的生命周期以响应路由变化?

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?

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

Moreover, a single pseudo-page may have several lists of data of the same type. For example, on a profile page, I want to show both Followers and Follows. How can a singleton UserStore work in this case? Would UserPageStore manage followedBy: UserStore and follows: UserStore?

推荐答案

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

In a Flux app there should only be one Dispatcher. All data flows through this central hub. Having a singleton Dispatcher allows it to manage all Stores. This becomes important when you need Store #1 update itself, and then have Store #2 update itself based on both the Action and on the state of Store #1. Flux assumes this situation is an eventuality in a large application. Ideally this situation would not need to happen, and developers should strive to avoid this complexity, if possible. But the singleton Dispatcher is ready to handle it when the time comes.

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

Stores are singletons as well. They should remain as independent and decoupled as possible -- a self-contained universe that one can query from a Controller-View. The only road into the Store is through the callback it registers with the Dispatcher. The only road out is through getter functions. Stores also publish an event when their state has changed, so Controller-Views can know when to query for the new state, using the getters.

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

In your example app, there would be a single PostStore. This same store could manage the posts on a "page" (pseudo-page) that is more like FB's Newsfeed, where posts appear from different users. Its logical domain is the list of posts, and it can handle any list of posts. When we move from pseudo-page to pseudo-page, we want to reinitialize the state of the store to reflect the new state. We might also want to cache the previous state in localStorage as an optimization for moving back and forth between pseudo-pages, but my inclination would be to set up a PageStore that waits for all other stores, manages the relationship with localStorage for all the stores on the pseudo-page, and then updates its own state. Note that this PageStore would store nothing about the posts -- that's the domain of the PostStore. It would simply know whether a particular pseudo-page has been cached or not, because pseudo-pages are its domain.

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

The PostStore would have an initialize() method. This method would always clear the old state, even if this is the first initialization, and then create the state based on the data it received through the Action, via the Dispatcher. Moving from one pseudo-page to another would probably involve a PAGE_UPDATE action, which would trigger the invocation of initialize(). There are details to work out around retrieving data from the local cache, retrieving data from the server, optimistic rendering and XHR error states, but this is the general idea.

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

If a particular pseudo-page does not need all the Stores in the application, I'm not entirely sure there is any reason to destroy the unused ones, other than memory constraints. But stores don't typically consume a great deal of memory. You just need to make sure to remove the event listeners in the Controller-Views you are destroying. This is done in React's componentWillUnmount() method.

这篇关于在 Flux 架构中，您如何管理 Store 生命周期?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！