React interview questions

The hook is useSyncExternalStore and its first argument is a subscribe function that React calls to register a callback notified on store changes. The second argument is getSnapshot, which returns the current store value. Filling in useSyncExternalStore for {{0}} and subscribe for {{1}} produces a correctly wired external-store subscription.

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.

Data flows down as props; a component manages its own state. Lifting state up means moving shared state to a common ancestor and passing it back down as props.

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.

When a context value changes, React re-renders every component that calls useContext with that context — regardless of whether the specific slice of data the component uses has changed. This is because useContext performs a reference equality check on the entire context value object. If the Provider's value is a new object literal on every parent render (e.g., value={{ user, setUser }}), all consumers re-render even if user hasn't changed. The only built-in escape hatch is to memoize the value with useMemo (or split contexts). React.memo on the consumer does NOT help because useContext bypasses the props-based bailout — the re-render is triggered by the context subscription, not by prop changes.

The bug is on line 4: const value = { user, dispatch }; creates a new object reference on every render of AuthProvider. Because useContext compares context values by reference (Object.is), every consumer re-renders whenever AuthProvider re-renders for any reason — even if user and dispatch haven't changed. The fix is to wrap the value in useMemo: const value = React.useMemo(() => ({ user, dispatch }), [user, dispatch]);. The dispatch function from useReducer is stable across renders, and user changing is a legitimate reason to re-render consumers, so the memoized value only changes when it should.

The correct pattern for avoiding unnecessary re-renders with complex context state is to split the context into a state context and a dispatch/setter context. Dispatch from useReducer is guaranteed stable (same reference every render), so components that only need to dispatch can consume the dispatch context and will never re-render due to state changes. Components that need state consume the state context and only re-render when state changes. Using a single combined context, even with useMemo, still re-renders all consumers on any state change. Using Redux or external state is not a React context technique. Passing values via props defeats the purpose of context. The multi-select correct answers are: splitting into separate state and dispatch contexts, and memoizing expensive child subtrees with React.memo/useMemo where appropriate.

React's useEffect dependency array uses Object.is (shallow referential equality) to compare each dependency between renders. An object literal { id: userId } is created fresh on every render, so its reference changes every time — even if userId hasn't changed. This causes the effect to re-run on every render, producing an infinite loop when combined with a setState call inside. The fix is to pass userId directly as the dependency (a primitive), or memoize the object with useMemo. Options about deep equality or batching are common misconceptions; React does not perform deep equality checks on deps.

The useEffect cleanup function returned from a prior effect run is called before the next effect fires (when deps change) and also on unmount. So the sequence is: mount → effect-1 runs; dep changes → cleanup-1 runs, then effect-2 runs; unmount → cleanup-2 runs. This ordering is critical for avoiding race conditions, for example cancelling a previous fetch before starting a new one. The AbortController pattern exploits this: the cleanup aborts the in-flight request from the previous render cycle.

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.