Context and React.memo

`React.memo` can skip re-renders caused by unchanged props, but it does not shield a component from updates to context values that the component reads. When a consumed context changes, React schedules that consumer to re-render even when its memoized props are unchanged.

`React.memo` memoizes a component based primarily on its props. If a parent renders the memoized component with the same props, React can reuse the previous result instead of rendering the component again.

Context is a separate input to a component. A component that calls `useContext(SomeContext)` subscribes to that context, so a change to the provider's value can cause the consumer to render again regardless of whether its props changed.

The comparison performed by `memo` does not treat consumed context as an ordinary prop. Therefore, wrapping a context consumer directly in `memo` does not make it insensitive to context updates.

A common optimization is to separate context reading from the expensive memoized component. An outer component reads the context and passes only the required value as a prop to a memoized child. The child can then skip work when that prop remains unchanged.

This optimization is most useful when the context changes frequently but a particular child only depends on a small part of the context. Stable provider values and appropriate component boundaries can also reduce unnecessary rendering.

Key points

• `React.memo` primarily skips renders when props are unchanged.
• A component consuming context can re-render when that context value changes.
• Context updates are not blocked by wrapping the consumer in `memo`.
• Move context consumption into a wrapper when you want a memoized child to depend on selected context data.
• Keep provider values stable when their contents have not meaningfully changed.

Interview questions

Does React.memo prevent a component from re-rendering when its consumed context changes?

No. `React.memo` can skip rendering when the component's props are unchanged, but a component that consumes a context is also affected by updates to that context. When the consumed context value changes, React can re-render the consumer even if its props are identical. Therefore, `memo` is not a way to opt out of context updates.

How would you optimize an expensive component that needs only part of a frequently changing context?

I would put the `useContext` call in a small wrapper component and pass the required piece of context to an expensive child as a prop. The child can be wrapped with `React.memo`, so it can skip rendering when that selected prop is unchanged. This creates a boundary between context subscription and expensive rendering. I would also check whether the provider is creating unnecessary new values.

Why might a context provider cause many consumers to render even when they use different fields of the context object?

A context consumer responds to changes in the context value as a whole rather than automatically selecting individual object fields for subscription. If the provider supplies a new object, consumers observing that context can be scheduled to update even when a particular field they read has not changed. Splitting contexts or introducing memoized boundaries can reduce unnecessary work. The right solution depends on the update frequency and component structure.

Can React.memo compare a component's consumed context value with its previous context value?

`React.memo` is a memoization mechanism for component rendering based on props, not a general context-selector mechanism. A context consumer has its own dependency on the context, and context changes can cause the consumer to update independently of the memoized props comparison. If fine-grained context subscriptions are required, the architecture needs a narrower subscription boundary or a context-selector-style approach rather than relying on `memo` alone. The exact behavior of advanced optimization mechanisms should be evaluated against the React version and API being used.