在 React.js 的日常開發中，我們經常會在某個 component 上巢狀包裹多層 Context Provider。這不僅讓程式碼看起來雜亂難讀，還會帶來維護上的困擾：一旦需要調整 Provider 的順序，就得大範圍修改 JSX 結構。尤其在專案規模擴大、團隊成員增加時，這類改動容易導致 Git commit 變更大量行數，進而提高 merge conflict 的風險。
例子：Provider Hell
以下這個例子就展示了典型的「Provider Hell」情境，有一堆的 context provider。
💡
我自己的習慣是建立一個 component 在裡面用 context provider，那麼 child component 便在 context 之中。也可以在這個 context component 裡面定義 context provider 的初始值。
💡
大家看到一個 context provider 重用很多次，但現實應該不會這樣做。這裡是因為舉例方便一些，不至於例子寫太長。解決方案：使用 Higher-Order Component (HOC) 來統一管理多層 Provider
為了簡化巢狀結構，我們可以建立一個 HOC wrapper function（withProviders），讓它自動為目標 component 套上多個 Context Provider。這樣一來：
- 只需將所有 Provider 以陣列形式傳入 HOC 即可自動完成巢狀包裹（陣列順序決定包裹層級）。
- 可在不同 component 上重用，程式碼更乾淨整潔。
- 調整順序時只需修改陣列順序，不會造成大規模 JSX 變更，大幅降低 conflict 風險。
HOC 的核心實作如下：
用法一：需要動態傳入 value 時（代碼稍長，但彈性高）
用法二：在 Provider 內部預先定義好初始 value（代碼最簡潔）
這樣在使用 HOC 時就不需額外傳值，直接放入 Provider component 本身即可
📕
後記如果希望在使用 HOC 時仍能動態傳入不同的初始值，用法一的代碼會較長。
若想追求極致簡潔，就採用用法二，但會犧牲部分彈性 (無法在同一 Provider 上傳入不同 value)。
當然兩種用法可以混合使用。
另一個小缺點是：難以重用相同 Provider 但提供不同 value 的情境——不過在實際專案中，這種需求不常見。
整體而言，這種 HOC 包裹技巧能有效解決多層 Context Provider 的痛點，讓程式碼更易維護，尤其適合中大型 React 專案使用。
參考
