在阅读了很多关于通量设计模式1的解释后，我非常了解它是如何工作的。
dispatcher 很像 JINI 2 查找服务。优点很明显，调度员不需要知道如何执行动作以及由谁来执行。它使您可以在持续集成中随时灵活地添加任何商店。
store 是模型和业务逻辑的直接封装。这里没问题，它只需要通知调度员自己，他就会收到动作和有效载荷，如果支持，就会执行动作。
视图是对商店数据的简单解释。但是通知它的方式，回调需要视图知道谁是商店，它是谁。此外，应用程序需要知道视图是谁以及获取它的人。
在我的理解中，视图破坏了可伸缩性，因为虽然你不需要知道动作是什么，但你需要知道结果是什么，视图需要知道商店是什么。除非我们在视图和存储之间以及客户端和视图之间使用另一种调度程序。
【问题讨论】：
标签： design-patterns reactjs reactjs-flux flux
您在技术上是正确的，尽管我还没有发现这是现实世界助焊剂应用中的痛点。部分原因是只有所谓的“控制器视图”才能访问通量存储，它们仅负责根据通量存储获取数据并将其转换为作为属性传递给其他组件的数据。
例如，在您链接到的 Fluxxor 的“什么是 Flux”页面中，有这张图片：
在这样的应用程序中，只有最顶部的“视图”框（带有来自商店的箭头的那个；也许它应该被标记为“控制器视图”）实际上知道商店并访问其中的数据；它下面的其他视图通过 props 获取数据（通常数据首先由控制器视图根据其子级的 propTypes 进行转换）。
[编辑：在现代通量应用程序中，这些通常被称为“容器”，除了通过道具连接普通组件和通量存储/动作之外什么都不做。]
如果您不喜欢这种方法，那么在商店和获取商店数据并以某种方式转换它的视图之间引入一个新概念将是微不足道的，这样任何视图都不需要知道商店（尽管这本质上是控制器视图所做的）。我也非常喜欢组合视图以将它们链接到商店的想法；示例见this Fluxxor issue。
【讨论】：