Flux 存储将更改发送到特定的 React 组件而不是所有组件。

努力寻找或想出一个优雅的答案：

如果我有多个动态反应组件正在侦听一个通量存储以更新其子组件，是否可以发出对特定组件的更改，而不是向注册以侦听该存储上的更改的所有组件发出更改？

例如：动态组件有一个按钮，单击时它会告诉通量存储将一些数据发送到 API。动态组件将根据通量存储发出的响应和更改来更新其子视图。但由于所有动态组件都在监听存储，它们都会更新它们的子视图，这是不期望的行为。理想情况下，通量存储可以识别将更改发送到哪个组件，或者组件可以识别该更改不适合它们。

这可能吗？还是违背了通量原则？

我不知道它是否违反了通量架构，但它似乎没有利用它的一些优点。

简单发出更改（没有更改细节）的优点在于，存储不需要对视图有明确的了解，而且使用 React Virtual Dom 框架，它不应该对性能造成太大影响。

为了进一步优化性能，您可以在React视图上实现shouldComponentUpdate（基于其自身属性的差异），以避免触发tree-diff算法。

看看这个：https://facebook.github.io/react/docs/component-specs.html https://facebook.github.io/react/docs/component-specs.html

==添加更多信息== 在更传统的 MVC 中，模型将发出对特定源和特定细节的更改，例如

this.emit({
    details: { x: 'x', y: 'y' },
    source: objectA
)};

接收此信息的视图（或控制器）需要此类详细信息来更新其 Dom，您将调用update(changes.details)而不是最初的render()方法，因为 Dom 操作的成本很高。

ReactJS 通过另一个虚拟 Dom 层“解决”了这个问题，该层使用纯 Javascript 来计算 Dom 操作中的“最佳”差异，因此在 React 中，你永远不会有方法调用update()，你总会打电话render()基于视图的当前状态，React 会为您进行优化。

因此，将 Flux 与 React 结合使用，您的存储可以发出没有任何细节的更改，并且侦听它的视图可以使用“最佳”Dom 操作进行渲染（因此，如果它的状态尚未更改，则不会有 Dom 操作）。 但当然，你会说在这种情况下 React 仍然会触发虚拟 Dom diff 计算，这仍然会花费一些费用。因此，要进一步优化它，您可以实施shouldComponentUpdate在包含大子树的视图上（基于它自己的状态），以避免 React 运行差异计算。

除了更简单的代码之外，发出简单更改的优点在于 Store 几乎可以与视图解耦。 例如，如果您触发特定视图的特定更改详细信息，那么当视图不再侦听该存储时，您将需要删除或更改存储中的代码。