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

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 的例子解释了这一点。有一个消息存储和一个线程存储。当动作例如。messagePost 被发出，它被分派到两个存储中，执行不同的工作来更新它们的属性。Threadstore 增加了未读消息的数量，messageStore 将新消息添加到其 messagearray 中。

因此，它基本上是引导一项操作在多个商店中执行数据更改。