javascript - React.js - 通量与全局事件总线

Question

与全局事件总线相比，使用 Flux 有什么优势？我认为调度程序就是所需要的：

1. 组件将带有数据的“用户事件”发布到调度程序
2. 调度程序执行订阅商店的处理程序
3. 处理程序使用商店的更新属性发布“更新事件”
4. 调度程序执行订阅组件的处理程序，并使用商店的更新属性更新组件状态

我在这里缺少什么是没有 Flux 做不到的？

Answer 1

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

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

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

Answer 2

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

Answer 3

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

假设您有appState哪些包含组件的基础数据。

组件调用action。Action 负责从 XHR 收集数据或修改来自组件的传入数据，然后将完整的数据发送到订阅的存储。

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

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

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

通量模式

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

这种方法的优点是：

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

Answer 4

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

4. 商店发出更改事件

并且更新其状态的组件不是通量的一部分，这是整合通量和反应的常见做法。

Flux 只是命名了这些部分，并就每个部分的职责给出了指导。

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

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