2016-09-07 27 views
9

随着我进一步实现redux + react到一个相当复杂的应用程序中,这个应用程序依赖于许多API请求来加载单个页面,所以我无法决定是否最好在页面处理所有异步的东西,并将道具传递给愚蠢的组件拥有多个容器组件,这些组件只关心他们需要的数据,以及获取他们需要的数据。我来回走了这两种模式之间,发现他们各有优点/缺点:React Redux:更多容器v.s.更少的容器

如果我把在顶部有一个单一的容器组件:

  • 亲:所有isFetching道具fetchSomeDependency()行动可以在一个地方处理。
  • con:真正令人讨厌的缺点是我发现自己必须通过多个组件转发道具和回调,并且树中间的某些组件最终与此绑定。

这里是问题的一个视觉的例子,显示关系所需的道具明智:

<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 />现在需要与拥有无关道具关注它看作是一种模式应该能够被重用,并且只关心模式的文体特征。

起初以上看起来不错,但一旦我有100多个组件,它们都感觉非常混乱,我发现这些顶级容器组件的复杂性对我来说太高了,因为它们中的大多数(在我正在工作的应用程序中)取决于来自3个API请求的响应。

于是我决定尝试多个容器:

  • 亲:完全消除需要转发的道具。在某些情况下做它仍然有意义,但它更加灵活。
  • 亲:方式更容易重构。我很惊讶我如何能够在没有任何突破的情况下大幅移动和重构组件,而在另一种模式中,事情却打破了很多。
  • 亲:每个容器组件的复杂性要小得多。我mapStateToPropsmapDispatchToProps是更具体的是在
  • CON组件的目的:依赖于异步东西的任何组件将始终需要处理本身isFetching状态。这增加了在单个容器组件中处理的模式中不必要的复杂性。

所以今天的主要困境是,如果我使用一个容器,我的根容器和叶片组件之间的部件得到这个非必要的复杂性。如果我使用多个容器,我在叶子组件中得到了更多的复杂性,并且最终得到的按钮需要担心isFetching,即使按钮不应该担心这一点。

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

谢谢!

回答

0

我一直看到的方式是将容器放在除root/app组件以外的逻辑组件组的最顶层组件中。

因此,如果我们有一个展示成果,让我们假设该组件heiarchy这样

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

我会做SearchResults Redux的认识容器一个简单的搜索应用程序。因为反应组分假设为可组合。您可能有其他组件或页面需要显示ResultsSearch。如果将数据提取和存储感知委托给根或应用程序组件,则会使组件相互依赖于其他应用程序。当您必须实施更改时,这使得它变得更加困难,现在您必须更改所有使用它们的地方。

这可能是一个例外,如果你真的有紧密耦合的组件之间的逻辑。即便如此,我还是会说,你应该创建一个容器来包装紧密耦合的组件,因为如果没有其他组件,它们将无法被真实地使用。

0

我甚至不会考虑使用单个容器方法。它几乎完全否定了redux的所有优点。如果你所有的状态都在一个地方,并且所有的回调都在一个地方(根组件),那么就没有必要拥有一个状态管理系统。

虽然我觉得有一条细线可以行走。我制作了一个应用程序,大约5周(兼职),现在它已经达到3000行。它有3个级别的视图嵌套,我自己实现的路由机制,以及深度超过10层的需要修改状态的组件。每个大屏幕基本上都有一个容器,它的功能非常好。

但是,如果我点击我的“客户”视图,我会得到一个客户列表,因为我的客户端视图位于redux容器中,并获取作为道具传递的客户端列表。然而,当我点击一个客户时,我真的很不愿为另一个客户的个人资料做一个redux容器,因为它只是一个额外的传递道具。看起来,根据应用程序的范围,您可能需要将道具传递至redux容器之后的1-2个级别,如果不止于此,则只需创建另一个Redux容器。再次,如果它是一个更复杂的应用程序,那么有时使用redux容器的混合以及其他一些不使用它们的时间可能会更糟糕的可维护性。简而言之,我的意见是尽可能减少Redux容器的数量,但绝对不会以复杂的道具链为代价,因为这是使用Redux开始的主要观点。

+0

请发表可读的解决方案。 – Sachith