What is a common, often negative, reputation of React Context regarding performance?
Context has a reputation for causing spontaneous and unstoppable re-renders, leading some developers to avoid it.
Contrary to its reputation, how can React Context positively impact performance when used correctly?
It can prevent unnecessary re-renders of intermediate components and significantly improve app performance.
What problem does lifting state to a common ancestor component to share it between distant children introduce, besides performance issues?
It leads to ‘prop drilling,’ where intermediate components receive and pass down props they don’t use, bloating their API.
In the ‘prop drilling’ example, why does clicking the ExpandButton cause VerySlowComponent inside MainPart to re-render unnecessarily?
Because the state is held in the parent Page component, and a state update there causes its entire component tree, including MainPart and its children, to re-render.
How does React Context solve the problem of ‘prop drilling’?
It allows passing data directly from a top-level provider component to a nested consumer component, bypassing all intermediate components.
When using Context with the ‘children as props’ pattern, why are intermediate components like Layout and Sidebar not re-rendered when the context’s state changes?
Because children are just props, and components do not re-render just because their parent’s state changes; only the consuming components are affected.
What hook is used to access the value provided by a React Context?
The useContext hook is used to access the context’s value.
When state inside a Context provider changes, which components in the application will re-render as a result?
Only the components that consume that specific context using the useContext hook will re-render.
What is the primary rule regarding re-renders for components that consume a React Context?
Context consumers will re-render every time the value prop on the Provider changes.
Why is it problematic if a component consuming a part of a context value re-renders when a different, unused part of that value changes?
It causes unnecessary re-renders, as the component re-renders even though the data it actually depends on has not changed.
Can React.memo or other standard memoization techniques easily prevent a context consumer from re-rendering when the context value changes?
No, these re-renders cannot be easily prevented with standard memoization techniques once the context value has changed.
What problem occurs if the value object passed to a Context Provider is re-created on every render of the provider component?
This causes a referential equality issue; the value is a new object every time, triggering a re-render in all context consumers even if the underlying data is the same.
In the example where a scroll state is added to the Layout component, why do all NavigationController context consumers re-render on every scroll event?
The scroll state change causes Layout to re-render, which in turn causes its child NavigationController to re-render, creating a new value object for the provider and triggering all consumers.
How can you prevent unintentional re-renders of context consumers caused by the provider’s parent re-rendering?
By memoizing the value passed to the provider using the useMemo and useCallback hooks.
Why is always memoizing the context provider’s value prop considered a good practice rather than premature optimization?
It prevents potentially large and hard-to-debug performance problems that can be introduced later if a parent component starts re-rendering.
A component uses only the open function from a context. Why will it still re-render when the isNavExpanded state (which it doesn’t use) changes?
Because the entire value object on the provider changes, and all components that consume the context will re-render, regardless of which part of the value they use.
What optimization technique involves creating multiple contexts to separate volatile state from stable functions?
Splitting providers.
In the ‘splitting providers’ pattern, one context would hold the changing state (data), while the other would hold _____.
the stable API functions that do not change
When splitting providers, why can’t a toggle function that depends on the current state be placed in the ‘stable API’ context?
Because its dependency on the state means the function would need to be re-created whenever the state changes, making the API context value unstable.
What React hook is recommended over useState to solve the issue of state-dependent functions in a split provider pattern?
useReducer.
In the useReducer pattern, what is the role of the dispatch function?
It allows components to send named ‘actions’ to the reducer to trigger state updates without needing to know the current state.
Why does using useReducer allow functions like toggle to be placed in a stable API context provider?
Because the dispatch function returned by useReducer has a stable identity, and API functions that only call dispatch do not depend on the state itself, so they also remain stable.
The reducer function accepts two arguments: the current state and the _____.
action
If you don’t want to refactor to use split providers or reducers, what trick can mimic context selectors to prevent re-renders?
Using a Higher-Order Component (HOC) combined with React.memo.
-
9. React Refs31
-
10. Closure in React27
-
8. React Context and Performance27
-
6. React Reconciliation35
-
1. Intro to re-renders27
-
3. Configuration concerns with elements24
-
2. Elements, children as props, and re-renders28
-
5. Memoization with useMemo, useCallback and React.memo36
-
7. Higher-order components in modern React24
-
4. Adv config with render props24
-
11. Implementing adv debouncing and throttling with Refs20
-
Interview prep9
