如何使用 Stores 管理 Flux/ReactJS 应用程序中的状态？

Question

在 FLUX/ReactJS 架构中，我很好奇以下方法是否违反（或不推荐）FLUX 流程。

1) 我们有 2 家商店。商店 A 和商店 B。

2) 我们有一个“App”组件，它的状态集来自 Store A，并将其传递给组件 1 和组件 2。

3) 组件 1 使用接收到的“this.props”中的数据并渲染内容。

4) 组件 2 使用接收到的“this.props”中的数据，但也有基于 Store B 的自己的状态（与“App 组件”的状态相同）。

据我了解——理想情况下——我会让“App Component”同时监听 Store A 和 Store B，并将所有内容传递给其他组件。

但是，在现实生活中的应用程序中，假设您有 100 个商店，每个商店都有自己的条件（您可以说如果不满足特定的数据组合，组件 2 不会被渲染，等等）。这将使 App 组件成为一个类似上帝的组件，可以处理这么多东西。在我看来不切实际。

在我看来，即使您没有顶级组件来管理所有状态并将其传递给组件，您仍然可以获得单向数据流 - 因为状态仍然由 Store 决定，而不是由组件本身（并且您通过 Actions->Dispatcher->Store 触发事件）。如果您想将特定行为封装在组件中，这在我看来特别好。

想象以下场景：

AppComponent -> AuthComponent -> LoginFormComponent

AppComponent -> ListItemsComponent -> SingleItemComponent

如果 AppComponent 知道“AuthStore”状态，这样它就可以通过 props 将它传递给 AuthComponent，这不是很奇怪吗？ 如果 AppComponent 什么都不知道（在这个例子中）并且只渲染 2 个孩子不是更好吗？ AuthComponent 将监听 AuthStore 并将信息传递给 登录表格; ListItemsComponent 将侦听 ListItemsStore 并将所需的信息传递给 SIngleItemComponent 等。

你们会采取哪种方法？

Answer 1

理论上，如果您的较低级别组件是完全隔离的，并且根据其状态，您需要更改较高级别（或同一级别）组件的状态的可能性为 0%，那么管理没有错它在组件本身中的状态。

但也有缺点：

1. 如果以后您决定使用更高级别的组件状态 您需要重构的层次结构。
2. 它使组件更少 可重复使用的。您需要拥有相同的商店、相同的操作等，而如果您通过道具接收状态，则可以更轻松地将其插入其他项目。
3. 它使测试变得更加困难。

我会说，如果它是一个大型独立组件，具有许多较低的组件，将状态保留在其中是有意义的，但通常应用程序中只有一个这样的组件。如果它只是一个小型的、单一用途的组件，那么这样做是没有意义的。