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請求的響應。
於是我決定嘗試多個容器：
- 親：完全消除需要轉發的道具。在某些情況下做它仍然有意義，但它更加靈活。
- 親：方式更容易重構。我很驚訝我如何能夠在沒有任何突破的情況下大幅移動和重構組件，而在另一種模式中，事情卻打破了很多。
- 親：每個容器組件的複雜性要小得多。我
mapStateToProps和mapDispatchToProps是更具體的是在 - CON組件的目的：依賴於異步東西的任何組件將始終需要處理本身
isFetching狀態。這增加了在單個容器組件中處理的模式中不必要的複雜性。
所以今天的主要困境是，如果我使用一個容器，我的根容器和葉片組件之間的部件得到這個非必要的複雜性。如果我使用多個容器，我在葉子組件中得到了更多的複雜性，並且最終得到的按鈕需要擔心isFetching，即使按鈕不應該擔心這一點。
我想知道是否有人找到了避免這兩個缺點的方法，如果有的話，您遵循什麼樣的「經驗法則」來避免這種情況？
謝謝！
請發表可讀的解決方案。 – Sachith