我喜歡在React和React Native項目中使用上下文,這意味著每個項目有多個上下文提供者。因此,我的應用程序的根目錄通常如下所示:
<ContextA.Provider value={valueA}>
<ContextB.Provider value={valueB}>
<ContextC.Provider value={valueC}>
// ...and so on until rendering actual app content
</ContextC.Provider>
</ContextB.Provider>
</ContextA.Provider>
這就形成了一個金字塔形的提供者,看起來和感覺都是糟糕的風格/做法。
我可以將我的上下文值合并到一個大提供者中:
<BigContext.Provider value={ valueA, valueB, valueC }>
/// app content
</BigContext.Provider>
…但是有一些很好的理由讓上下文保持獨立-主要是防止只對valueA
感興趣的組件在valueB
發生變化時從re-rendering中分離出來。
即使沒有上下文,您仍然可以將來自不同包的提供者堆疊到它們自己的金字塔中。下面是我的一個React Native應用程序的根目錄,例如:
<DataContext.Provider value={data}>
<AppearanceProvider>
<SafeAreaProvider>
<NavigationContainer>
<Tab.Navigator>
// tab screens here
</Tab.Navigator>
</NavigationContainer>
</SafeAreaProvider>
</AppearanceProvider>
</DataContext.Provider>
有沒有一個干凈的方法來“崩潰”,或以某種方式避免,這些金字塔的厄運?
“清理”所謂的末日金字塔對性能沒有任何好處。有多個層次是完全好的。
在實現下面的代碼之前,請確保不要僅僅因為可以就在全局級別提供上下文。上下文提供程序必須包裝在使用它的組件附近,這意味著不總是在根級別。
也就是說,這里有一個簡單的高階組件,它可以包裝多個提供者以提供Redux
compose
式API。Usage:
再說一次,有多個層次是完全好的。