6

React鼓励尽可能多地使用无状态组件，并有一个有状态的父组件来管理它们。我知道这可以使无状态组件更加可重用，并且易于管理。但是，到了极点，我们总是可以把 state 放在最顶层的组件上，比如 App.js，通过一个长长的 props 链来传递信息和回调。如果使用 Flux，动作也总是可以在其中调度（通过回调执行）。

所以我想知道分离有状态和无状态组件的路线是什么？如果使用 Flux，Action 应该在哪里分派？

--- 添加一个例子 ---

假设我有一个像网络应用程序这样的谷歌文档，它有一个工具栏和显示的内容。我想我们会有组件结构。

<App>
    <Toolbar />
    <Content />
</App>

工具栏有会影响显示内容的按钮，比如粗体文本按钮。

那么 App 应该将 onButtonPressed 回调 props 传递给 Toolbar 并自行调度 Actions，还是应该让 Toolbar 自己做呢？

App 应该将 contentString props 传递给 Content，还是让 Content 自己监听 Store 的变化？

谢谢！

4

2 回答 2

1

从我的角度来看，一个简单的应用程序可以以这种方式使用 Flux 模式：

  1. 儿童发出动作。
  2. 该应用程序侦听存储并将处理后的数据传播给他的孩子。

使用这种方法，您拥有无状态组件，但具有良好的代码组织，没有回调道具。但是您的两个命题也是正确的，这是您根据应用程序的大小和需求做出的决定。

如果您构建的组件将在您的应用程序之外使用，请尽可能不要使用通量，让开发人员根据自己的需要选择想要的方法。

于 2015-09-09T07:47:59.283 回答
0

这是一个很好的问题，即使在不同的 Flux 实现之间也有不同的解决方法。

我更喜欢将我的状态放在一个高级组件中，它可以看到“大图”，并使用道具将数据传播到所有低级组件。在一个好的 React 应用程序中，大多数组件不应该“关心”数据的来源。到目前为止，拥有一个良好的结构化模型而不是几个零散的模型也证明自己是有益的。（顺便说一句，即使使用几个商店也可以实现，高级组件可以听取所有这些，并虚拟“持有”这个大模型）。

关于动作——我更喜欢让我所有的“愚蠢”可视化/用户界面/显示组件与回调道具一起工作。这样就更容易重用它们，并且很好地分离了关注点。在包含一些业务逻辑的更丰富的组件中，我直接调用 Reflux 操作。通常这些也是前面提到的“哑” ui 控制器的容器组件。

所以底线 - 数据应该从尽可能高的位置流出，可以从较低的组件触发操作，但始终检查是否可以使用回调道具获得相同的结果。

对于您的问题 - Toolbar 是一个足够复杂的组件，可以拥有自己的 ToolbarActions 并直接调用它们。但是 Content 组件绝对应该从上面获取它的数据。当应用程序变得复杂时，以这种方式推理数据流也更容易。

希望有帮助。整个 Flux 的事情仍在进行中……

于 2015-09-27T01:19:21.220 回答