React Flux:存储依赖关系

事件化方法的问题在于，您无法保证哪个处理程序将首先处理给定的事件。因此，在一个非常大、复杂的应用程序中，这可能会变成一个复杂的网络，你不确定什么时候会发生什么，这使得商店之间的依赖关系管理非常困难。

基于回调的调度器的好处有两个：存储更新自己的顺序在需要这种排序的存储中声明，而且它还保证完全按预期工作。这也是Flux的主要目的之一——使应用程序的状态具有可预测性、一致性和稳定性。

在一个保证不会随着时间的推移而增长或改变的非常小的应用程序中，我无法反驳你的建议。但小型应用程序最终有向大型应用程序发展的趋势。这种情况经常发生在任何人意识到它正在发生之前。

Flux当然还有其他方法。已经创建了相当多的不同实现，它们对这个问题有不同的方法。然而，我不确定这些实验中哪一个规模很好。另一方面，Facebook的Flux回购中的调度器和文档中描述的方法已经扩展到真正巨大的应用程序，并且经过了充分的战斗测试。

在我看来，这个调度器在某种程度上是反模式的。

在基于事件源或CQRS的分布式体系结构中，自主组件不必相互依赖，因为它们共享相同的事件日志。

并不是因为你在同一台主机（浏览器/移动设备）上，就不能应用这些概念。然而，具有自主存储（无存储依赖性）意味着同一浏览器上的2个存储可能具有重复数据，因为2个不同的存储可能需要相同的数据。这是一个成本，但我认为从长远来看，它有好处，因为它消除了对商店的依赖。这意味着您可以完全重构一个存储，而不会对不使用该存储的组件产生任何影响。

在我的例子中，我使用这样的模式并创建某种自主的小部件。一个自主的小部件是：

• 侦听事件流的存储
• 一个组件
• 一个LESS文件（因为React Styles，现在可能没用了？）

这样做的好处是，如果给定的小部件上有错误，那么除了上面提到的3之外，该错误几乎不会涉及任何其他文件；）

缺点是托管相同数据的存储也必须维护它。在某些事件中，许多存储可能不得不对其本地数据执行相同的操作。

我认为这种方法更适合大型项目。

在这里查看我的见解：Om但在javascript 中