Question

我开发的应用程序最初是使用Flux构建的。

然而，随着时间的推移，应用程序变得更难维护。有一个非常大量的行动。通常只能在一个地方收听一个动作（商店）。

操作可以不在一个地方编写所有事件处理程序代码。所以不要这样：

store.handleMyAction('ha')
another.handleMyAction('ha')
yetAnotherStore.handleMyAction('ha')

我可以写：

actions.myAction('ha')

但是我从不使用那种行为。我几乎可以肯定，这不是我申请的问题。

每次拨打电话时，我都可以拨打store.onSmthHappen而不是action.smthHappen。

当然，在多个地方处理一个动作时会有例外情况。但是当发生这种情况时，感觉就会出现问题。

如果不是调用动作而是直接从商店调用方法怎么样？我的申请会不会那么灵活？没有！仅发生重命名（极少数情况下）。但是要付出什么代价！通过所有这些操作来理解应用程序中发生的事情变得更加困难。每次跟踪复杂动作的处理时，我都必须在处理它们的商店中找到。然后在这些商店中我应该找到调用另一个动作的逻辑。等等。

现在我来找我的解决方案：

有控制器直接从商店调用方法。如何处理操作的所有逻辑都在商店中。还存储对WebAPI的调用（通常是与一个WebAPI相关的一个商店）。如果事件应在多个商店中处理（通常顺序），则控制器通过编排从商店返回的承诺来处理此事件。私有方法中的一些序列（常用）。控制器的方法可以将它们用作处理的简单部分。所以我永远不会复制代码。

控制器方法不返回任何内容（单向流）。

实际上，控制器不包含如何处理数据的逻辑。它只是，以什么顺序。

您几乎可以看到商店中数据处理的完整图片。商店里没有关于如何与其他商店互动的逻辑（通过它就像多对多关系，只是通过行动）。现在，商店是一个高度凝聚力的模块，只负责域模型（集合）的逻辑。

主要（在我看来）助焊剂的优势仍然存在。

因此，有商店，唯一真正的数据来源。组件可以订阅商店。组件调用与以前相同的方法，而不是actions使用controller。与React 的交互完全没有改变。

此外，事件处理变得非常明显。现在我可以看一下控制器中的处理程序，一切都变得清晰，调试起来要容易得多。

问题是：

为什么行动创造了变化？我错过了哪些优势？

Answer 1

实现捕获视图或服务器上的某个交互的操作，然后可以根据需要将其分派到多个不同的存储。开发人员用facebookchat的例子解释了这一点。有一个messageStore和一个threadstore。当行动例如。发布了messagePost，它被派遣到两个商店做不同的工作来更新他们的属性。 Threadstore增加了未读消息的数量，messageStore将新消息添加到其messagearray中。

因此它基本上引导了一个动作来在多个商店中执行datachange。

Answer 2

我和你有同样的问题和思考过程，现在我开始使用Flummox，这使得Flux架构更加清晰。

我在我定义Store的同一个文件中定义了我的动作，这已足够接近了。我仍然可以订阅调度程序来记录事件，这样我就可以看到所有被调用的操作，并且我可以选择在需要时创建多商店操作。

它附带了一个很好的FluxComponent，它允许您将所有与商店相关的代码包装在一个地方，因此它的子代是无状态组件，可以更新商店更改，例如

  <FluxComponent connectToStores={['storeA', 'storeB']}>
    <InnerComponent />
  </FluxComponent>

保持Flux架构（它在幕后使用Facebook的Flux）有望使其易于使用GraphQL等其他技术。

我为什么要在Flux中使用Actions？

2 个答案: