4

所以我最近在玩 React 和 Flux 架构。

假设有 2 个 Store A 和 B。A 依赖于 B，因为它需要 B 的一些值。所以每次调度程序调度一个动作时，首先执行 B.MethodOfB，然后执行 A.MethodOfA。

我想知道与将 A 注册为 B 的侦听器并在每次 B 发出更改事件时仅执行 A.MethodOfA 相比，这种架构有什么优势？

顺便说一句：考虑一下没有来自 facebook 的示例调度程序的“switch case”的 Flux 实现！

4

2 回答 2

8

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

基于回调的调度程序的好处是双重的：商店更新自身的顺序在需要此排序的商店中声明，并且还保证完全按预期工作。这是 Flux 的主要目的之一——让应用程序的状态可预测、一致和稳定。

在保证不会随时间增长或变化的非常小的应用程序中，我无法与您的建议争论。但小型应用程序最终会发展成大型应用程序。这通常发生在任何人意识到它正在发生之前。

Flux 当然还有其他方法。已经创建了相当多的不同实现，它们对这个问题有不同的方法。但是，我不确定这些实验中的哪些可以很好地扩展。另一方面，Facebook 的 Flux 存储库中的调度程序和文档中描述的方法已经扩展到真正巨大的应用程序，并且经过了实战考验。

于 2014-09-23T17:07:59.677 回答
2

在我看来，我认为这个调度程序在某种程度上是一种反模式。

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

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

就我而言，我使用这样的模式并创建某种自治小部件。自治小部件是：

  • 监听事件流的商店
  • 一个组件
  • 一个 LESS 文件（由于 React Styles 现在可能没用了？）

这样做的好处是，如果给定小部件上存在错误，则该错误几乎从不涉及除上述 3 之外的任何其他文件；）

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

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

在这里查看我的见解：Om but in javascript

于 2014-10-29T15:18:12.693 回答