A React tree renders <ThemeContext value="dark"> around the page and, deeper inside it, <ThemeContext value="light"> around a modal. What does a component inside the modal read, and what is nesting the same context deliberately good for?
answer
- nearest one wins for its subtree
- nothing is combined or layered
- position in the rendered tree, not the file
- two mounts, two independent states
- state dies when its Provider unmounts
basics
~20 sIt reads "light": React returns the nearest matching Provider above the reader, and values do not merge. Deliberate nesting scopes a value to a subtree — a local override, or a fresh independent instance of a Provider that owns state.
solid answer
~50 sThe modal reads `"light"`. React resolves a context by walking up from the reading component to the **nearest** Provider for that context object, so the inner one shadows the outer for its whole subtree, and everything outside the modal still sees `"dark"`. Note the values do not combine — there is no merge. If you want the inner value to *extend* the outer one, read the outer value in a component and pass a new merged object down explicitly. Deliberate nesting is how you scope context: an inverted-theme panel, a per-row or per-field context in a list or form, an embedded widget that needs its own settings. And if the Provider component owns state internally, each mounted instance has its own independent state — so nesting gives you two separate scopes, not a shared one, which is exactly right for something like a per-dialog form context.
go deeper
Remember that the nearest Provider above a component supplies its value, so an inner Provider overrides an outer one for everything inside it.
Explain that values replace rather than merge, and that position in the rendered tree — not where a component is defined — decides which Provider it reads.
Demonstrate the consequences you have hit in production: a stateful Provider mounted twice gives two disconnected scopes, and Provider placement decides when that state is discarded.
Own the convention — where Providers may be mounted, whether scoped overrides are supported at all, and what you publish so teams override values consistently instead of ad hoc.
## The resolution rule ```jsx <ThemeContext value="dark"> <Sidebar /> {/* reads "dark" */} <ThemeContext value="light"> <Modal /> {/* reads "light" */} </ThemeContext> </ThemeContext> ``` A component reading `ThemeContext` gets the value of the **nearest** Provider above it in the rendered tree. "Above" means the tree React actually renders, not the file the component is defined in — a component passed as `children` is positioned where it is *rendered*, so it sees the providers wrapping the JSX that created it, not the ones wrapping the component that received it as a prop. That distinction is what makes composition-based overrides work at all. The inner Provider shadows the outer one only for its own subtree. Siblings outside it are unaffected, and once you leave the inner subtree the outer value applies again. ## Values do not merge This is the most common misunderstanding. Context has no notion of layering or partial override: ```jsx <Config value={{ locale: 'en', currency: 'USD' }}> <Config value={{ currency: 'EUR' }}> <Price /> {/* reads { currency: 'EUR' } — locale is GONE */} </Config> </Config> ``` If you want extension semantics, you build them yourself: read the outer value, spread it, and provide the result. ```jsx function ConfigOverride({ patch, children }) { const outer = useConfig(); const merged = useMemo(() => ({ ...outer, ...patch }), [outer, patch]); return <Config value={merged}>{children}</Config>; } ``` Shipping that small override component alongside the Provider is a good API decision — it makes the merging explicit and stops every feature team from reinventing it slightly differently. ## Two Providers, two states When the Provider is not just passing a literal but owns state internally, nesting a second instance creates a **second, independent** state: ```jsx export function WizardProvider({ children }) { const [step, setStep] = useState(0); const value = useMemo(() => ({ step, setStep }), [step]); return <WizardContext value={value}>{children}</WizardContext>; } ``` Mount one around the page and another inside a dialog, and the dialog's wizard advances without touching the page's. That is a feature when the scope is genuinely per-instance (a modal's own wizard, a form per row, a drag context per board column) and a bug when you intended one shared scope and accidentally mounted the Provider twice — for example once in a layout and once in a route component. The symptom is unmistakable: writes through one subtree's hook never show up in the other. The corollary is lifetime. State lives as long as its Provider stays mounted. Unmount the dialog and its Provider goes with it, discarding that scope's state — often exactly what you want, and a reason to mount a Provider at the subtree rather than at the root. ## Legitimate uses of deliberate nesting - **Local visual overrides** — a dark toolbar inside a light page, or the inverse. The subtree reads the override; the rest of the app is untouched. - **Per-item scopes** — each row of a list wraps its children in a Provider carrying that row's item, so deeply nested cells read "my row" without prop drilling through every level. - **Embedded or third-party surfaces** — an embedded widget mounts its own Provider so it is insulated from whatever the host app provides. - **Testing and previews** — a Storybook decorator or test wrapper mounts a Provider with fixed values around one component, overriding whatever the app would normally supply. ## What to be careful about Accidental shadowing is the flip side. A Provider mounted "just to be safe" inside a layout will silently cut the subtree off from the outer scope, and because context never warns about shadowing, the only evidence is behaviour that disagrees between two parts of the app. When you debug context, the first question is always *which* Provider instance a component is actually reading — React DevTools shows the resolved context value per component, which settles it in seconds. ## What interviewers listen for Say "nearest Provider wins" without hesitating, correct the merge misconception, and then show you know the second-order consequence: a stateful Provider mounted twice means two independent scopes, with lifetimes tied to where it is mounted.
- How do you make an inner Provider extend the outer value rather than replace it?Read the outer value inside a component, merge it with your patch, and provide the result: `const merged = { ...outer, ...patch }`. React gives you no layering, so the merge is ordinary JavaScript. Publishing that as a small override component next to the Provider keeps every feature from writing its own slightly different version.
- A component defined inside a Provider is passed as children to a component rendered outside it. Which Provider does it read?The one wrapping where it is rendered in the tree, which is the outer position of the element it was created in — not the providers around the component that received it as a prop. Element position in the rendered tree decides context, and this is precisely why passing children through works so predictably.
- How do you tell an intentional scoped Provider from an accidental duplicate?Ask whether the subtree is supposed to have its own lifetime and its own writes. Intentional scoping is per-instance state — a dialog's wizard, a row's item. An accidental duplicate shows up as writes in one part of the app never appearing in another; DevTools resolving two different values for the same context confirms it.
saying these in an interview costs you the question
- Says nested context values merge or layer
- Thinks the outermost Provider wins
- Believes context resolves by file location, not tree position
- Assumes two Provider instances share one state
- Expects React to warn when a Provider is shadowed