Detailed explanation
useContext is a React Hook that lets a component read and subscribe to a context value supplied by an ancestor. It is useful when several components need the same information, but passing that information through every intermediate component would create prop drilling. Typical examples include theme, locale, authentication information, and a feature-specific state shared across a subtree. Context does not have to be application-wide: placing a provider around one section limits where its value is available.
First, create a context outside your components: const ThemeCtx = createContext('light'). Then wrap the relevant subtree with <ThemeCtx.Provider value="dark"><App /></ThemeCtx.Provider>. Inside a descendant function component, const theme = useContext(ThemeCtx) returns 'dark'. React finds the nearest matching provider above that component, so nested providers can override values for smaller subtrees. If there is no matching provider, React returns the default supplied to createContext. That default is a static fallback, not state; a provider explicitly passing undefined makes consumers receive undefined instead. A provider returned by the consuming component itself does not affect that component's useContext call.
Context distributes a value; it does not manage state by itself. Usually, the provider component uses useState or useReducer and supplies state together with functions that update it. React compares the previous and next provider values using Object.is. When the value differs, React re-renders components that read that context, even if they are wrapped in React.memo. An inline object or function can therefore trigger context updates whenever the provider renders because its reference is new. Memoizing the supplied object and callbacks can avoid unnecessary reference changes, while splitting unrelated contexts reduces the number of affected consumers.
Use context when shared access makes the component tree clearer, not as a replacement for every prop. Keep local state local, and prefer explicit props for simple parent-child relationships. For frequently changing shared data with many independent subscriptions, consider a store with selector-based subscriptions. Interviewers generally look for correct provider lookup, an understanding of subscription-driven rendering, and sensible decisions about state ownership and performance.
Key points to remember
- useContext reads and subscribes to the nearest matching ancestor provider.
- The createContext default is used only when no matching provider exists.
- Context avoids prop drilling and can be scoped to any subtree.
- State updates come from useState, useReducer, or another state source—not context itself.
- Provider value changes use Object.is comparison and re-render consumers; React.memo does not block these updates.
Common mistakes candidates make
- Assuming context is automatically global or manages state on its own.
- Passing a fresh object on every provider render without recognising that its new identity can update all consumers.
- Expecting consumers to update only when the particular field they read changes; useContext subscribes to the whole context value.
Likely follow-up questions
How can a consumer update a context value?
The provider can expose a setter, dispatch function, or named action alongside the state. A consumer calls that function, which updates the provider's state and produces a new context value.
How do you reduce unnecessary context re-renders?
Split unrelated or differently paced values into separate contexts, and stabilise provider objects and callbacks with useMemo and useCallback where useful. These techniques avoid unnecessary updates, but they do not prevent consumers from re-rendering when their context value actually changes.
Should context replace Redux or another external store?
Not automatically: context distributes values, whereas external stores may provide selectors, middleware, and specialised debugging tools. Context with useReducer can suit modest shared-state needs, while a selector-based store may better support complex state with frequent, targeted updates.
Interview tip: Explain nearest-provider lookup first, show the theme example, then mention one appropriate use case and the re-render trade-off.