在不断变化的建筑，你如何管理存储生命周期？ [英] In Flux architecture, how do you manage Store lifecycle?

问题描述

我在阅​​读有关流量不过的例如待办事项应用过于简单，我了解一些关键点。

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.

在助焊剂架构，这将如何对应于存储和调度员？

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?

此外，单个伪页面可以具有相同类型的数据的多个列表。例如，在个人资料页上，我想同时显示关注的和的跟随的。如何在这种情况下，一个单身 UserStore 工作？将 UserPageStore 管理​​ followedBy：UserStore 和如下：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?

推荐答案

在一个流量的应用程序应该只有一个调度程序。所有的数据流通过这一中央枢纽。有一个单调度允许它来管理所有存储。当你需要存储＃1更新本身这变得很重要，然后还要根据双方的行动和对商店＃1的状态存储＃2更新本身。助焊剂假设这种情况在大型应用程序的可能性。理想的情况是这种情况下就不需要发生，并且开发人员应该尽量避免这种复杂性，如果可能的话。但单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.

商店单身为好。他们应该保持独立和分离地 - 一个自包含的宇宙，人们可以从一个控制器 - 视图查询。唯一的路进店就是通过它与调度注册回调。唯一的路出来就是通过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的新闻源，其中帖子来自不同的用户出现在帖子。其逻辑域是职位列表，它可以处理的帖子中的任何名单。当我们从伪页面移动到伪页面，我们要重新初始化存储的状态，以反映新的状态。我们可能还需要缓存在localStorage来previous状态作为优化伪页面之间来回移动，但我的倾向是设置了一个 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 将有一个初始化（）方法。这种方法将永远清除老态，即使这是第一次初始化，然后创建基于它通过行动接收到的数据的状态下，通过调度。从一个伪页面移动到另一个可能会涉及 PAGE_UPDATE 的行动，可能会触发的调用初始化（） 。有细节各地从本地缓存中检索数据，从服务器，乐观的渲染和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.

如果一个特定的伪页面不需要在应用程序中所有的商店，我不能完全肯定有任何理由摧毁未使用的，除了内存的限制等。不过，卖场一般不占用内存很大。你只需要确保删除你正在破坏控制器的视图的事件侦听器。这是在做作出反应的 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.

这篇关于在不断变化的建筑，你如何管理存储生命周期？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！