问这个通量动作和这个函数调用之间有什么区别？

EN

磁通式建筑的主要特点大致如下：

1. 存储是应用程序状态的唯一真实来源。
2. 只有操作才能触发存储状态的变异
3. 不应直接更改存储状态，即通过分配对象值，而应通过克隆/析构来创建新对象。

就像节食一样，如果你滑倒，断断续续地回到原来的方式，使用这种架构真的不起作用。

回到你的例子。在这里使用操作的好处不是广播或记录方面，而仅仅是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的数据和基于该状态的调度操作。存储处理不同的操作与状态之间的协调，以便所有订阅者在正确的时间拥有正确的数据。

当您只有一两个实体使用的几个商店时，这种模式的好处可能并不明显。当您有数十(或数百)个存储区，其中有几十个(或数百个)组件使用来自多个商店的数据时，这种体系结构可以使您更容易开发新特性而不破坏现有特性，从而节省了您的时间和金钱。

希望这墙上的文字有助于澄清！

我不明白的是，如何将动作以JSON对象的形式，突然强制或帮助“单向”通信流，这是我在任何地方读到的，有动作和流动的巨大优势。在我看来，无论我如何香水猪，我仍然在有效地向商店发送信息。当然，该操作在到达存储之前正在经历几层间接(动作创建者，dispatcher)，但是除非我遗漏了一些东西，否则为所有实际目的发送该操作的组件正在更新任何存储正在侦听杀死消息的内容。我在这里错过了什么？

Facebook的想法来自事件驱动的GUI系统。在那里，即使你移动你的鼠标，你也会收到消息。这当时被称为message循环，现在我们有了操作调度。

此外，我们有在商店内的订户名单。

在Redux中，您有一个商店，而在Flux中，您可能有多个商店，这是相同的原则。

现在是小小的数学。有两个组件A和B，你只需要有几个可能的更新链A更新B和B更新A，或自我更新(不包括在这里从应用程序外部的更新)。这是可能的情况。

​

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

​

​

有了更多的组件，它就变得复杂起来。因此，为了抑制可能的组件交互的指数复杂性，我们有一个Flux模式，如果您使用来自其他编程语言的这些接口，它的作用不过是IDispatch、IObservable。一种是吐痰动作，另一种是进入商店内存在的侦听器链。

使用此模式，您的React代码将以与普通React方法不同的方式进行组织。您不再需要使用React.Component状态了。相反，您将使用保存应用程序状态的Store(s)。

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

由于组件负责基于应用程序状态进行呈现，因此我们需要以某种方式将它们传递给应用程序状态。它可能是通过props = store.getState()或者我们可以使用上下文。同时也要检查这。

最后，在不影响应用程序的情况下，组件使用内部状态(this.state)甚至是不被禁止的。你应该承认这些案子。