Re-render Cascade
One state update makes a component and a big branch beneath it render again, even though only a small part of the screen needed new work.
See it
What it is
When a React component's state changes, React renders that component again and, by default, walks through its descendants too. One update near the top can therefore call a large subtree of component functions. That is a re-render cascade. It does not mean React rewrites the whole DOM: the commit phase applies only the changes it finds.
Reach for a fix only after the React DevTools Profiler shows expensive work. Turning on 'Highlight updates when components render' in the DevTools settings makes the cascade visible as flashing outlines before you touch any code. Start by moving state closer to the components that need it or passing stable children around a stateful wrapper. Then use React.memo for a costly child and useMemo or useCallback only where stable references actually let that boundary skip work.
Gotcha: React.memo compares props shallowly. A fresh object, array, or function created on every parent render is a new prop and breaks the skip. Blanket memoization adds comparison work and clutter, so profile the interaction again after each change.
Ask AI for it
Profile this interaction with the React DevTools Profiler and identify the state update that starts the widest re-render cascade. Move that state to the lowest component that owns it, or pass stable children through the stateful wrapper. Add React.memo only around descendants whose render is measurably expensive, and use useMemo or useCallback only when a fresh object or function prop prevents that memo boundary from skipping work. Report the before-and-after commit duration and list every component that stopped rendering.