reactjs - React Redux : More containers v. 秒。更少的容器

Question

当我进一步将 redux + React 实现到一个相当复杂的应用程序中(该应用程序依赖于许多 API 请求来加载单个页面)时，我很难决定是否在页面根部使用单个容器组件更好它处理所有异步内容并将 props 传递给愚蠢的组件。拥有多个容器组件，这些组件只关心它们需要的数据，以及获取它们需要的数据。我在这两种模式之间来回研究，发现它们各有利弊:

如果我将单个容器组件放在顶部:

• 专业人士:全部isFetching Prop 和fetchSomeDependency()操作可以在一个地方处理。
• 缺点:真正令人烦恼的缺点是我发现自己必须通过多个组件转发 props 和回调，而树中间的某些组件最终会与此相关联。

这是该问题的直观示例，显示了 props-wise 所需的关系:

<MyContainer
  data={this.props.data}
  isFetchingData={this.props.isFetchingData}
  fetchData={this.props.fetchData}
 >
   {!isFetchingData && 
     <MyModal
        someData={props.data}
        fetchData={props.fetchData}
      >
       <MyModalContent
         someData={props.data}
         fetchData={props.fetchData}
       >
          <SomethingThatDependsOnData someData={props.someData} />
          <SomeButtonThatFetchesData  onClick={props.fetchData} />
        </MyModalContent>
      </MyModal>
    }
 </MyContainer>

如您所见，<MyModal />和<MyModalContent />现在需要关心与之无关的 Prop ，因为模态应该能够被重用，并且只关心模态的风格品质。

起初，上面看起来很棒，但是一旦我有了 100 多个组件，一切都感觉非常困惑，而且我发现这些顶级容器组件的复杂性对于我来说太高了，因为它们中的大多数(在我正在开发的应用程序)取决于 3 个以上 API 请求的响应。

然后我决定尝试多个容器:

• 专业版:完全消除了转发 props 的需要。在某些情况下这样做仍然有意义，但它更加灵活。
• 专业人士:更容易重构。我很惊讶我如何能够在不破坏任何内容的情况下显着地移动和重构组件，而在其他模式中，事情会破坏很多。
• 优点:每个容器组件的复杂性要低得多。我的mapStateToProps和mapDispatchToProps更具体地说明其所在组件的用途。
• 缺点:任何依赖于异步内容的组件始终需要处理 isFetching本身的状态。这增加了在单个容器组件中处理的模式中不必要的复杂性。

所以主要的困境是，如果我使用一个容器，我会在根容器和叶组件之间的组件中获得不必要的复杂性。如果我使用多个容器，叶组件会变得更加复杂，最终会出现需要担心的按钮 isFetching即使按钮不应该关心这一点。

我想知道是否有人找到了避免这两个缺点的方法，如果是的话，您遵循什么“经验法则”来避免这种情况？

谢谢!

Answer 1

我一直认为将容器放在逻辑组件组的最顶层组件中，而不是根/应用程序组件。

因此，如果我们有一个简单的搜索应用程序来显示结果，并假设组件层次结构是这样的

<Root> <- setup the app
  <App>
    <Search/> <- search input
    <Results/> <- results table
  </App>
</Root>

我会制作 Search 和 Results redux 感知容器。因为 react 组件应该是可组合的。您可能有其他组件或页面需要显示结果或搜索。如果将数据获取和存储感知委托(delegate)给根或应用程序组件，则会使组件相互依赖/应用程序。这使得当您必须实现更改时变得更加困难，现在您必须更改所有使用它们的地方。

异常(exception)情况可能是组件之间确实有紧密耦合的逻辑。即使如此，我还是想说，您应该创建一个容器来包装紧密耦合的组件，因为如果没有彼此，它们将无法实际使用。