我认为其他人对应用程序结构和change事件的看法很重要，但我应该补充一点：

调度程序的waitFor方法是使用调度程序注册商店与监听全局事件总线的商店之间的最大区别。此方法可让您管理哪些存储在其他存储之前更新。当您希望 StoreB 在决定做什么之前首先查看 StoreA 做了什么时，这变得至关重要。

您可以将调度程序视为具有waitFor方法的全局事件总线，这在一定程度上是准确的。

我不是通量方面的专家，但架构不能让您做以前不可能做的事情，它为您的应用程序提供了一个可扩展和可理解的结构。

我相信这都是关于代码结构的，即使在大规模的情况下也是可以理解的。

假设您拥有appState它保存组件的基础数据。

组件调用action。Action 负责从 XHR 收集数据或修改从组件传入的数据，然后将完整的数据分派到订阅的商店。

Store 是您代码的唯一部分，它可以修改您的代码，appState并且基本上是唯一的东西，它可以做什么。它从动作中获取数据，并根据动作将它们存储appState或删除一些数据appState。

然后你触发stateChanged事件，你的组件应该监听并重新渲染。

因此，您在操作中拥有所有特定于操作的逻辑。您appState只能在商店办理。这应该可以帮助您保持代码易于理解。

通量模式

我对为什么只发送完整数据是个好主意的理解主要来自这篇文章。它基于官方 Facebook Flux 图

这种方法的优点是：

• 存储简单且同步，不包含决策逻辑，只处理给定的数据
• 无需在 store 中触发另一个动作，这将打破 Flux 的单向链
• 调度器是所有状态变化的单一通道，它知道处理什么数据的动作，因此更容易调试

您基本上描述了通量，唯一的区别是：

4. 商店发出更改事件

更新其状态的组件不是flux的一部分，这是集成flux和react的常见做法。

Flux 只是为这些部分命名，并就每个部分的职责提供指导。

它本质上是一个主要的事件发射器（调度器）、事件类型（动作）、在调度器上发出事件的函数（动作创建器；事件体是一个有效载荷），以及其他事件发射器：保持状态，监听调度器并发出更改事件（存储）。

至少它在 JS 中是这样工作的。核心原理是单向数据流。有很多用于双向通信的事件发射器。