所以我最近玩的是React和Flux架构。
假设有2个商店A和B.A对B有依赖性，因为它需要来自B的一些值。所以每次调度员调度一个动作时，首先执行B.MethodOfB，然后执行A.MethodOfA。
我想知道这个体系结构的优势在于将A注册为B的监听器，并且每次B发出更改事件时只执行A.MethodOfA？
顺便说一句：想想没有来自facebook的示例调度员的“切换案例”的Flux实现！
答案 0 :(得分：8)
解决方法的问题在于，您无法保证哪些处理程序将首先处理给定事件。因此，在一个非常庞大，复杂的应用程序中，这可能会变成一个纠结的网络，你不确定在什么时候发生了什么，这使得商店之间的依赖管理变得非常困难。
基于回调的dispatcher的好处有两个：商店更新自身的顺序在需要此排序的商店中声明，并且保证完全按预期工作。这是Flux的主要目的之一 - 使应用程序的状态可预测，一致且稳定。
在一个非常小的应用程序中，保证不会随着时间的推移而增长或改变，我无法与你的建议争论。但小应用程序最终会逐渐成长为大型应用程序。这经常发生在任何人意识到它发生之前。
当然还有其他的Flux方法。已经创建了相当多的不同实现，并且它们具有针对该问题的不同方法。但是，我不确定这些实验中哪些可以很好地扩展。另一方面，Facebook's Flux repo中的调度员和documentation中描述的方法已经扩展到真正巨大的应用程序，并且经过了严峻的考验。
答案 1 :(得分：2)
在我看来，我认为这个调度员在某种程度上是一种反模式。
在基于事件源或CQRS的分布式体系结构中，自治组件不必彼此依赖，因为它们共享相同的事件日志。
这不是因为您在同一主机（浏览器/移动设备）上无法应用这些概念。然而，具有自主商店（没有商店依赖性）意味着同一浏览器上的2个商店可能具有重复数据，因为2个不同商店可能需要相同的数据。这是一个支付成本，但我认为从长远来看，它有利于消除存储依赖性。这意味着您可以完全重构一个商店，而不会对不使用该商店的组件产生任何影响。
就我而言，我使用这样的模式并创建某种自治小部件。自治小部件是：
这样做的好处是，如果给定小部件上存在错误，则该错误几乎不会涉及除上述3之外的任何其他文件;）
缺点是托管相同数据的商店也必须维护它。在某些事件中，许多商店可能必须对其本地数据执行相同的操作。
我认为这种方法可以更好地扩展到更大的项目。
请在此处查看我的见解：Om but in javascript