React interview questions: rendering, re-renders and reconciliation

The key prop gives React a stable identity for each list item so it can match elements between renders without relying solely on index position. When keys are unique and stable, React can reorder, add, or remove items efficiently. Using array indices as keys is an anti-pattern when the list order can change, but a key is not the same as a component's id prop — it's a special hint consumed by React and not passed down to the component.

On the initial mount the component renders once. useState(0) initialises count to 0, so <p>{count}</p> displays 0 and the button displays its label Click me. The question asks only about the visible DOM output on first mount, which is unambiguous regardless of Strict Mode or bailout behaviour: the user sees 0 and the button text Click me.

The bug is on line 6: key={index}. Using the array index as a key is problematic when the list can be reordered, filtered, or have items added/removed at positions other than the end. React uses key to identify which items have changed between renders. When indices shift (e.g., an item is prepended or deleted), React reuses the wrong DOM nodes, causing stale or swapped content. The fix is to use a stable, unique identifier from the data itself (e.g., key={fruit.id} or key={fruit} if values are unique).

React.memo wraps a function component and shallow-compares props; when they're unchanged React skips rendering the child entirely. React.PureComponent does the equivalent shallow comparison of props and state via a built-in shouldComponentUpdate for class components. Both are React's documented, first-class mechanisms for preventing unnecessary child re-renders. useCallback alone only stabilizes a function reference; without React.memo/PureComponent on the child, the child still re-renders whenever the parent does — reference stability without a bail-out mechanism on the child changes nothing. useMemo inside the child memoizes a value used during rendering; it does not stop the child from being rendered in the first place — by the time the memoized computation is consulted, the child's render function is already executing. useReducer in the parent just manages the parent's state and provides no mechanism to gate child re-renders.

React's reconciliation compares elements by their type. When the type changes at a given position in the tree (e.g., from <Counter /> to <div>), React unmounts the old component and mounts a new one — all local state is destroyed. When type stays the same, React updates the existing instance and preserves state. Here, toggling showInput changes the element at the second position from <Counter /> to <footer> and back. Each toggle unmounts and remounts Counter, resetting its count to 0. The correct ordering of React's reconciliation steps when a type mismatch is detected is: tear down old tree → create new tree → commit to DOM.

Without stable keys React falls back to index matching, which moves state to the wrong items when the list changes. Keys are about identity, not ordering.

React's reconciliation algorithm (the 'diffing' algorithm) makes several key assumptions to keep complexity at O(n) instead of O(n³). (1) Elements of different types produce entirely different trees — React will tear down the old tree and build a new one rather than trying to patch across types. (2) The developer can hint at stable identity across renders using the key prop; React uses keys to match children in a list. React does NOT diff across sibling positions without keys, and it does NOT perform cross-level tree moves — if a subtree moves to a different depth, React unmounts and remounts it rather than relocating the fiber. The claim ('React reuses DOM nodes when a component type changes if the props are identical') is false, and the claim ('React diffs the full tree depth-first before committing any changes') misrepresents the algorithm — React uses a two-phase approach (render + commit), but the diffing itself is depth-first per fiber, not a separate full-tree pre-pass. The two correct heuristics are differing element types and the key prop.

This question tests understanding of React's fiber bailout mechanism and referential equality. React.memo wraps Child and performs a shallow prop comparison. On the second render triggered by setCount, style is an object literal { color: 'red' } created inline. Even though its shape and values are identical to the previous render's object, it is a new reference each time — so the shallow comparison (===) fails, and Child re-renders. items is defined with useMemo and has no changing dependencies, so it retains the same reference and passes the memo check alone. But because style fails, Child re-renders regardless. The fix would be to also memoize style with useMemo or useCallback. The correct answer is that Child does re-render on every parent render, despite React.memo.

Keys drive identity during reconciliation. A different key at the same position forces a remount, which is the idiomatic state-reset technique instead of syncing props into state via effects.

When a component's key changes, React treats it as an entirely different component identity: the old subtree is unmounted and a fresh one is mounted. useEffect callbacks (both setup and cleanup) are passive effects — they are scheduled asynchronously via React's internal scheduler (using a MessageChannel post-message or similar mechanism) and run after the browser has been given the opportunity to paint, though a visible paint is not strictly guaranteed before the flush fires. Within a single passive-effects flush, React's implementation consistently processes all cleanups for unmounted components before running setup effects for newly mounted components, so logExit(1) precedes logView(2). The correct answer correctly captures both the observed behavior and the important nuance that this cross-instance ordering is an implementation detail of React 18 rather than an explicitly documented specification guarantee. The claim that logView(2) is called first because the new instance's mount effect is enqueued before the old instance's cleanup is processed is incorrect: cleanups for destroyed fiber trees are processed before new mount effects in the same flush, not after. The claim that only logView(2) is called because the key changed and React reuses the existing fiber and skips running the old cleanup entirely is incorrect: a key change always triggers a full unmount/remount, so the cleanup is always invoked. The claim that logExit(1) and logView(2) are both called synchronously during the commit phase, before the browser has had any opportunity to schedule a repaint is incorrect: useEffect is asynchronous and deferred; it is useLayoutEffect that runs synchronously after DOM mutations but before paint.