Flux实际上更多是关于应用程序状态管理，而不是关于在视图中呈现哪些组件的细节。那就是React的领域。Flux只是假设您具有某种反应性视图层-
通常是React。

应用程序状态与组件状态不同。应用状态是需要在多个组件中了解的状态。对于组件状态，React
this.state完全足够。输入组件是可能需要此功能的一个很好的例子。

因此，在您的情况下，如果只有一个组件需要知道滚动位置，则可能没有很好的理由将该状态移至Flux
Store。但是，一旦需要在多个组件（尤其是树的不同分支中的组件）中知道这一点，您就可能希望在商店中对该状态进行管理。

您提出的另一个问题是助焊剂作用的作用。Flux应用程序始终使用操作作为数据流的来源。这样做有很多很好的理由：稳定的应用程序状态，保持应用程序对新功能的适应力，易于推理，撤消历史记录，重构应用程序状态，无状态视图组件等。

有时人们希望编写尽可能少的代码，并且他们使用在组件之间传递的回调来更改this.state父组件，而不是调度新操作以通过Flux数据流。我发现这混和了应用程序的视图和状态管理层，尽管很方便，但这可能会引起很多麻烦。从长远来看，它不是很灵活，因为现在状态与这几个组件相关。从长远来看，从一开始就构建Flux数据流要简单得多，并且对新功能的适应能力也要强得多。也就是说，它还需要在代码上进行更多的投资。