React · Advanced interview

On a state change React re-runs the component to produce a new element tree (the render phase) and diffs it against the previous tree using the Fiber reconciler — same type and key means reuse and update, otherwise unmount and mount. The render phase is pure and interruptible. Then the commit phase applies the computed DOM mutations synchronously and runs layout effects, followed by passive effects (useEffect) after paint. Keeping render pure is what lets React pause, abort, and restart work under concurrent rendering.

It compares element type and key at each position. Same type + same key → it reuses the existing Fiber/DOM node and updates props and state in place. Different type → it unmounts the old subtree (running cleanup) and mounts a new one, losing that subtree's state. Keys disambiguate siblings of the same type, which is why stable keys preserve state across reorders and why a changing key is a deliberate way to force a remount.

React groups multiple state updates that happen in the same tick into a single re-render. Since React 18 this batching is automatic everywhere — event handlers, promises, timeouts, native callbacks — not just React event handlers. If you genuinely need an update applied synchronously and flushed (e.g. to measure the DOM before the next line), flushSync opts out of batching for that update, at a performance cost.

Concurrent rendering lets React prepare a new UI in the background and interrupt or abandon that work to stay responsive, instead of rendering in one blocking pass. useTransition marks a state update as a non-urgent transition so urgent updates (typing) aren't blocked, and gives you an isPending flag. useDeferredValue lets a value lag behind its source so expensive work driven by it can be deprioritized. Both keep the interface responsive when an update triggers heavy rendering.

const [isPending, startTransition] = useTransition();
startTransition(() => setQuery(next));

A component can 'suspend' while data isn't ready; the nearest <Suspense> boundary shows its fallback until the data resolves, then swaps in the content — no manual loading flags scattered around. With streaming SSR the server sends the shell immediately and streams each boundary's HTML as its data resolves, so the user sees content progressively and hydration happens in chunks rather than after everything is ready.

Server Components render only on the server: their code never ships to the browser, they can access server resources (DB, filesystem) directly, and they can't use state or effects or browser APIs. Client Components (marked 'use client') ship JS and run in the browser with full interactivity. RSC matter because they cut bundle size and let you fetch data at the source, while you opt into client JS only at the interactive leaves — a default-server, escalate-to-client model.

'use client' marks a module as the boundary where the app transitions from the server to the client bundle. That component and everything it imports for rendering becomes part of the client bundle and can use hooks, state, and browser APIs. Server Components can render client components and pass serializable props to them, but not the other way around. You push the directive as far down the tree as possible to keep more of the app server-only.

useEffect runs asynchronously after the browser paints; useLayoutEffect runs synchronously after DOM mutations but before paint. Use useLayoutEffect only when you must read layout (measure a node) and synchronously re-style or scroll before the user sees a flash — for example positioning a tooltip. It blocks paint, so it's the exception; default to useEffect.

It's the official hook for subscribing to an external store (a state library, a browser API like online status) in a way that's safe under concurrent rendering. It prevents 'tearing' — different parts of one render reading different versions of the store — by giving React a consistent snapshot, and it supports a server snapshot for SSR. Library authors use it; app code usually consumes it through the library.

const value = useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot);

Match the tool to the change frequency and scope. Local or lifted useState/useReducer for state a subtree owns. Context for low-frequency, widely-read values (theme, auth) — not for fast-changing data, since all consumers re-render. An external store (Redux, Zustand, Jotai) with selector-based subscriptions for high-frequency or large shared state, so components re-render only on the slices they read. The deciding factors are how often it changes and how many components read it.

Measure first with the React DevTools Profiler to see which components render, how often, and why (the 'why did this render' data). Then attack the cause: memoize expensive computations, stabilize props with useMemo/useCallback and React.memo for hot children, split or memoize context, virtualize long lists, and mark heavy non-urgent updates with useTransition. Verify each change against the profiler rather than scattering memoization blindly.

An error boundary is a component (using componentDidCatch / getDerivedStateFromError) that catches render-time errors in its subtree and shows a fallback instead of unmounting the whole app. Its limits: it doesn't catch errors in event handlers, asynchronous code, SSR, or itself — those you handle with try/catch and state. Place boundaries around independent regions so one failing widget doesn't take down the page.

Concurrent React may call a component multiple times, pause it, or throw away the result before committing. If render has side effects — mutating external state, writing the DOM, starting requests — those run on renders that may never commit or may run twice, causing duplicated work and inconsistent UI. Keeping render pure (effects go in useEffect, mutations go through state) is what makes interruptible, restartable rendering safe.