这是一个关于管理店内依赖关系的合理方法的问题。我有一个应用程序，为系统的各个部分提供各种仪表板。系统的每个部分都有一个专用的控制器视图和存储。
我现在正在开发一个整体仪表板，它将代表每个现有商店公开的仪表板数据的顶级摘要。鉴于每个商店都有相当数量的转换，我希望我的新SummaryStore依赖于每个现有商店并从每个商店中提取数据。很好，干。
系统具有非常高的数据吞吐量。每个专用商店在收到调度员的操作时，将确定该操作是否会改变该特定商店的状态（通常不会），如果有，则仅调用emitChange()。这最大限度地减少了UI的重新渲染量。
我想保留那个＆＃34;只有在你需要时才会发出变化。使用摘要商店的方法。如何理智地实现这一点？
目前我有很多选择：
hasChanged上公开一个属性，当该商店的状态发生变异时为真，否则为假。在我的waitFor中使用SummaryStore，听取与专用商店相同的事件，并且仅在专用商店emitChange() hasChanged true时触发SummaryStore 这种方法似乎相当合理和务实。我看到的缺点是让这家商店有效地知道其他商店将在waitFor中响应和重新实施哪些操作，因此我们在FluxStore中细化。但这并不是那么糟糕。我还注意到，这种完全相同的方法似乎已在官方FluxUtils中使用SummaryStore：http://facebook.github.io/flux/docs/flux-utils.html#api
emitChange()听取每个专用商店的emitChange()，并仅在这些回调中的SummaryStore中更改状态/ emitChange()。您甚至可以将Dispatcher注册包装起来。争议！这有可能使事情变得非确定性，因为当waitFor来自专用商店时会发生突变。当然，你仍然可以使用SummaryStore（如果你保持Dispatcher注册），但是我不清楚这是否会让你回到你想要的确定性，这可能会导致一个不清楚的架构。我做了一些挖掘工作，看到没有其他人有商店听商店的证据。相反，这给我留下了警钟 - 但也许这是非理性的。
SummaryStore不会订阅与专用商店相同的消息，而只会订阅专用商店提出的操作。这非常好地使用调度程序机制（除非我遗漏了某些内容）消除了复制waitFor中每个专用存储的消息订阅代码的需要。不需要Users: <a,b,c,d>, Primary key a Int, B: Map<Int,Date>
所有爵士乐，只需让它响应每个商店发送的动作。唯一让我停下来思考的是
问题是，其中哪一项最多＆＃34; Flux方式＆＃34;？