尽可能地反应encourages无状态组件的使用，并有一个有状态的父组件来管理它们。 据我所知，这可以使无状态组件更易于重用，并且易于管理。 但是，在极端情况下，我们总是可以将状态置于顶级组件（如App.js），并通过长道具链传递信息和回调。如果使用Flux，也可以始终在其中调度操作（通过回调执行）。
所以我想知道分离有状态和无状态组件的界限是什么？如果使用Flux，应该在哪里调度Actions？
---添加一个例子---
假设我有一个类似于网络应用的谷歌文档，其中包含工具栏和显示的内容。我想我们将拥有组件结构。
<App>
<Toolbar />
<Content />
</App>
工具栏上有影响显示内容的按钮，比如粗体文本按钮。
那么App应该将onButtonPressed回调道具传递给工具栏并自行调度动作，还是应该让工具栏自行完成？
App应该将contentString传递给内容，还是让内容本身监听存储更改？
谢谢！
答案 0 :(得分：1)
从我的观点来看，一个简单的应用程序可以这样使用Flux的模式：
使用这种方法，您拥有无状态组件，但具有良好的代码组织而没有回调道具。但是你的两个命题都是正确的，这是你对应用程序的大小和需求做出的决定。
如果您构建的组件将在您的应用程序之外使用，请尽量不要使用flux，并让开发人员根据自己的需要选择所需的方法。
答案 1 :(得分：0)
这是一个很好的问题，即使在不同的Flux实现之间也会有不同的解决方案。
我更喜欢在一个高级组件中使用我的状态，看到＆＃34;大图片＆＃34;，并使用props将数据传播到所有低级组件。在一个好的React应用程序中，大多数组件都不应该关注＆＃34;数据来自何处。 拥有一个好的结构化模型而不是几个零碎的模型也证明了自己到目前为止是有益的。 （顺便说一句，即使使用多个商店也可以实现，高级组件可以听取所有这些，并且实际上可以“保持这个大模型”）。
关于行动 - 我更喜欢拥有我所有的＆＃34; dumb＆＃34;可视化/ ui /显示组件与回调道具一起使用。这样就可以更容易地重复使用它们，这是一个很好的分离问题。 在拥有一些业务逻辑的更丰富的组件中，我直接调用Reflux操作。通常那些容器组件本身也是前面提到的“哑巴”＃34; ui控制器。
所以底线 - 数据应尽可能高，可以从较低的组件触发动作，但总是检查是否可以使用回调道具获得相同的结果。
对于您的问题 - 工具栏是一个足够复杂的组件，可以拥有自己的ToolbarActions并直接调用它们。但是内容组件肯定应该从上面获取其数据。当应用程序变得复杂时，以这种方式推理数据流也更容易。
希望有所帮助。整个Flux事物仍然是一门艺术......