这个通量动作和这个函数调用有什么区别？答案

【问题标题】：what is this difference between this flux action and this function call?这个通量动作和这个函数调用有什么区别？
【发布时间】：2017-06-10 03:57:33
【问题描述】：

我可以有一个这样的通量操作：

{type: 'KILL', payload: {target: 'ogre'}}

但我没有看到像这样在类 People（包装商店）上有一个方法有什么区别，

People.kill('ogre')

如果人是行动的唯一接收者？

我看到通量调度程序给了我两个优势（可能）

“kill”方法可以广播到多个未知接收者（好！）
调度员为我提供了一个方便的地方来记录所有操作流量（也不错！）

这些肯定是好事，但还有其他我想念的原因吗？

我没有看到将动作以 JSON 对象的形式放置，如何突然强制或帮助“单向”通信流，这是我在各处阅读的内容，这是拥有动作的最大优势，以及通量。

在我看来，无论我如何给猪上香，我仍在有效地向商店发送信息。当然，该动作现在在到达商店之前要经过几层间接（动作创建者，调度程序），但除非我遗漏了什么，否则出于所有实际目的发送该动作的组件正在更新任何商店正在侦听杀死消息。

我在这里缺少什么？

我再次知道在 Stack Overflow 上我们不能问太笼统的问题，所以我想保持这个非常具体。这两个 sn-ps 代码虽然具有不同的语法，但在语义上（除了广播到多个商店的可能性）似乎完全相同。

如果唯一的原因是它启用广播并启用单点流以进行调试，我对此很好，但想知道是否还有其他关于通量/调度程序的事情我错过了?

【问题讨论】：

标签： reactjs flux

【解决方案1】：

flux-style架构的主要特点大致如下：

商店是应用程序状态的唯一真实来源
只有动作可以触发商店状态的突变
不应直接改变存储状态，即通过分配对象值，而是通过克隆/解构来创建新对象

就像节食一样，如果你滑倒并间歇性地回到旧的方式，使用这种类型的架构真的不起作用。

回到你的例子。在这里使用操作的好处不是广播或记录方面，而只是People 类应该只能使用来自存储的数据并表达其希望通过操作改变所述存储的状态的事实。例如，想象Elves 想对食人魔唱歌，因此有兴趣知道该食人魔还活着。同时People 想要有礼貌，不想在小夜曲中杀死食人魔。通量式架构的好处显而易见：

class People {
  kill(creature) {
    if (creatureStore.getSerenadedCreature() !== creature)
      store.dispatch({ type: 'KILL', payload: { target: creature } })
    return `The ${creature} is being serenaded by those damn elves, let's wait until they've finished.`
  }
}

class Elves {
  singTo(creature) {
    if (!creatureStore.getCreatures().includes(creature))
      return store.dispatch({ type: 'SING_TO', payload: { target: creature } })
    return `Oh no, the ${creature} has been killed... I guess there will be no serenading tonight..`
  }
}

如果People 类要包装存储，您还需要Elves 类来包装同一个存储，创建两个相同状态将以一种或另一种方式发生变化的地方。现在想象一下，如果有 10 个其他类需要访问该存储并想要更改它：添加这些新功能变得很痛苦，因为所有这些类现在都受其他类的支配，从它们下面改变状态，迫使你处理大量与这些类的业务逻辑无关的极端情况。

使用通量样式架构，所有这些类将仅使用来自creatureStore 的数据并根据该状态调度操作。商店负责协调不同的操作与状态，以便其所有订阅者在正确的时间拥有正确的数据。

如果您只有几个商店，每个商店由一个或两个实体消费，这种模式的好处可能并不明显。当您拥有数十个（或数百个）商店，其中有数十个（或数百个）组件使用来自多个商店的数据时，这种架构可以让您在不破坏现有功能的情况下更轻松地开发新功能，从而节省您的时间和金钱。

希望此墙文字有助于澄清！

【讨论】：

【解决方案2】：

我没有看到将动作以 JSON 对象的形式放置，如何突然强制或帮助“单向”通信流，这是我在各处阅读的内容，这是拥有动作的最大优势，以及通量。在我看来，无论我如何给猪上香，我仍在有效地向商店发送信息。当然，该动作现在在到达商店之前要经过几层间接（动作创建者，调度程序），但除非我遗漏了什么，否则出于所有实际目的发送该动作的组件正在更新任何商店正在侦听杀死消息。我在这里缺少什么？

Facebook Flux 从事件驱动的 GUI 系统中汲取灵感。在那里，即使你移动鼠标，你也会收到消息。这被称为消息循环，现在我们有动作调度。

此外，我们还有商店内的订阅者列表。

在 Redux 中你有一个 store，而在 Flux 中你可能有多个 store，这实际上是相同的原则。

现在是小数学。拥有 2 个组件 A 和 B，您只需要几个可能的更新链 A 更新 B 和 B 更新 A，或自我更新（此处不包括来自应用程序外部的更新）。这是可能的情况。

只需三个组件，我们就有更多可能的链。

如果组件越多，它就会变得复杂。因此，为了抑制可能的组件交互的指数复杂性，我们有这种 Flux 模式，如果您使用来自其他一些编程语言的这些接口，则无非就是IDispatch、IObservable。一种是用于发送动作，另一种用于进入存在于 store 中的侦听器链。

使用这种模式，您的 React 代码将以不同于常见 React 方法的方式组织。您将不再需要使用React.Component 状态。相反，您将使用将保存应用程序状态的 Store。

您的组件只能通过调度操作来显示改变应用程序状态的愿望。例如：onClick 可以调度操作来增加计数器。动作是具有属性type: 的对象，它通常是一个字符串，并且通常是大写的，但是动作对象可能有许多其他属性，例如 ID、值、...

由于组件负责根据应用程序状态进行渲染，我们需要以某种方式为它们提供应用程序状态。它可以通过props = store.getState() 或者我们可以使用context。但也要检查this。

最后，甚至不禁止组件使用内部状态（this.state），以防这对应用程序没有影响。你应该认识到这些情况。

【讨论】：