7

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

然而，随着时间的推移，应用程序变得越来越难以维护。有非常多的动作。而且通常一个动作只能在一个地方（商店）听到。

Actions 使得不用在一个地方编写所有事件处理程序代码成为可能。所以代替这个：

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

我可以写：

actions.myAction('ha')

但我从不那样使用动作。我几乎可以肯定，这不是我的应用程序的问题。

每次我调用一个动作时，我都可以调用store.onSmthHappen而不是action.smthHappen.

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

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

现在我来解决我的问题：

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

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

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

您几乎可以在 Store 中看到数据处理的全貌。商店中没有关于如何与其他商店交互的逻辑（使用通量，它就像多对多关系，但只是通过动作）。现在 store 是一个高度内聚的模块，只负责领域模型（集合）的逻辑。

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

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

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

问题是：

为什么动作是在不断变化的？我错过了他们的哪些优势？

4

2 回答 2

4

实现的操作是为了捕获视图上或来自服务器的特定交互，然后可以将其分派到任意数量的不同商店。开发人员以 facebookchat 为例对此进行了解释。有一个 messageStore 和一个 threadstore。当动作例如。messagePost 被发出，它被分派到两个商店做不同的工作来更新他们的属性。Threadstore 增加了未读消息的数量，并且 messageStore 将新消息添加到其消息数组中。

所以它基本上是引导一个动作在多个商店中执行数据更改。

于 2014-12-01T13:57:21.157 回答
2

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

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

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

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

保留 Flux 架构（它在幕后使用 Facebook 的 Flux）有望使其他技术（如GraphQL ）的使用变得容易。

于 2015-06-06T16:45:01.477 回答