A React app's root has grown into eight nested context providers wrapping <App />. How do you tame that pyramid, and what does the nesting order actually mean?

## What the nesting order means Providers nest, so each one renders inside all of the ones above it. That matters the moment a provider is more than a value carrier: ```jsx function ThemeProvider({ children }) { const { user } = useAuth(); // reads AuthContext const value = user?.prefersDark ? 'dark' : 'light'; return <ThemeContext value={value}>{children}</ThemeContext>; } ``` `ThemeProvider` can only work when an `AuthProvider` is above it. Put it outside and `useAuth()` throws — which, if you have the throwing-hook pattern, is a loud and correctly-placed error rather than a silent misconfiguration. So the root's nesting is a **topological order over provider dependencies**. Providers with no dependencies are unordered and interchangeable; providers that consume another context are constrained. Interviewers like this question because a candidate who says "order doesn't matter, they're all just wrappers" has never debugged one. ## Step one: stop putting everything at the root The most effective fix is deleting providers from the root, not formatting them better. Ask of each: *which subtree actually reads this?* - A checkout context belongs around the checkout route, not the app. - A wizard or form context belongs around the dialog that owns it. - A drag-and-drop context belongs around the board. Moving a provider down buys three things beyond a shorter root. Its state is created when the subtree mounts and discarded when it unmounts, which gives you free reset semantics. Its blast radius shrinks to the subtree. And the dependency is legible: reading the route file tells you what that route needs, instead of every feature's requirements being smeared across one root file. With route-based code splitting, mounting a provider inside a lazily loaded route also keeps its module out of the initial chunk. ## Step two: name what remains What is genuinely global — auth, i18n, a query client, toasts, error boundaries — goes into one component: ```jsx export function AppProviders({ children }) { return ( <ErrorBoundary> <AuthProvider> {/* ThemeProvider reads auth — must stay inside */} <ThemeProvider> <ToastProvider>{children}</ToastProvider> </ThemeProvider> </AuthProvider> </ErrorBoundary> ); } ``` This is often the right stopping point. The nesting is visible, props are natural, the order constraints can be commented where they apply, and — importantly — tests and Storybook can import the same `AppProviders` so the test environment cannot drift from production wiring. Note that error boundaries and Suspense boundaries are part of this stack and their position is semantic too: they only catch what is *below* them, so a boundary placed inside a provider cannot catch that provider's own render error. ## Step three: fold it, if you want flat ```jsx const providers = [ErrorBoundary, AuthProvider, ThemeProvider, ToastProvider]; export function AppProviders({ children }) { return providers.reduceRight( (acc, Provider) => <Provider>{acc}</Provider>, children ); } ``` `reduceRight` builds from the innermost outward, so the array reads top-to-bottom exactly like the JSX did. To pass props, make the entries tuples and destructure them in the reducer. Be honest about what this achieves: it is **formatting**. The runtime tree is identical, the order constraints are identical, and you have traded explicit JSX for an array whose semantics are less obvious to the next reader — the array now *looks* like an unordered list of features while actually being an ordered dependency chain. It also fights TypeScript on per-provider props. Use it when you truly have a long list of prop-less, order-independent providers; keep explicit JSX otherwise. ## What does not fix it A few tempting non-solutions: merging every concern into one giant context (you have traded a readable pyramid for a value object that everything depends on and nothing can be reasoned about); rendering providers as siblings (they only supply their own subtree, so this simply does not work); and reaching for a store library purely to shorten the root file, which is choosing an architecture to solve a formatting complaint. ## What interviewers listen for The order-is-dependency insight first, then relocation before decoration, then a clear-eyed statement that a compose helper is cosmetic. A candidate who leads with the `reduceRight` trick and never mentions moving providers down has optimised the wrong thing.