Walk through what happens when state changes. What are the three phases?
Whether you understand React is declarative and diff-based, not imperative DOM manipulation.
(1) Render — a state/prop change marks the component dirty; React calls your function to produce a new element tree (pure, no DOM touched yet). (2) Reconcile — React diffs the new tree against the previous one using keys and element type to find the minimal set of changes. (3) Commit — React applies those changes to the real DOM and then runs layout effects, then paints, then passive effects (useEffect). Understanding this explains why keys matter and why effects run after paint. A few consequences fall straight out of this model: render must be pure because React may call it multiple times or throw it away (concurrent features, StrictMode's double-invoke in dev exist to surface impurity); setState during render of the same component is how you derive state, but setState in an effect triggers a second render-commit cycle before paint only for useLayoutEffect. Reconciliation bails out early when the element type is identical and props are shallow-equal under React.memo, and it throws away the entire subtree when the type differs — which is why a changing key (or a conditional that swaps component type) remounts and resets state. 'Why did this re-render' almost always traces back to: parent re-rendered, state/context changed, or a new object/function identity defeated memoization.
Reasoning about re-renders, why a wrong key remounts a component, and when effects fire relative to paint.