Advanced React Interview Questions and Answers

After a state change, React renders a new element tree and compares it with the previous one. If an element's type at a position is the same, React keeps the DOM node and component instance (and its state) and updates props; if the type differs, it unmounts the old subtree and mounts a new one. In lists, keys identify items across renders, so reordering moves instances instead of rebuilding them. Consequences: changing a key deliberately resets a component's state; defining a component inside another component creates a new type every render and wipes its state.

memo skips re-rendering a component when its props are shallowly equal; useMemo caches a computed value; useCallback caches a function identity. They help with expensive renders, expensive calculations, and keeping props stable for memoised children or effect dependencies. They cost memory and comparisons, add dependency arrays that can go stale, and do nothing when props are new objects every render. Profile first; prefer structural fixes (moving state down, passing children). The React Compiler can insert memoisation automatically at build time.

Batching groups several state updates into one re-render. Since React 18, updates are batched automatically everywhere, including inside promises, timeouts and native event handlers, not only in React event handlers. flushSync forces an immediate update when you genuinely need the DOM updated synchronously (rare).

startTransition (or useTransition) marks an update as non-urgent. React keeps the UI responsive by handling urgent updates (typing) first and rendering the transition in the background, interrupting it if newer input arrives. useDeferredValue gives a lagging copy of a value for a similar effect. Typical use: filtering a large list while the input stays responsive.

With server-side rendering, React renders components to HTML on the server so users see content before JavaScript loads. In the browser, React hydrates that HTML: it renders the same tree and attaches event handlers to the existing DOM. If the client's first render differs from the server HTML (for example using Date.now(), Math.random(), window or locale-dependent formatting during render), React reports a hydration mismatch. Fix it by rendering deterministic output and moving browser-only values into effects.

Components that run only on the server (or at build time). They can be async, read databases and secrets directly, and send their rendered output to the client without adding their code to the JavaScript bundle. They cannot use state, effects or browser APIs; interactive parts are Client Components marked with "use client". Server Components can render Client Components and pass them serialisable props. Frameworks such as Next.js implement them.

<Suspense fallback={...}> shows a fallback while something inside is not ready: lazily loaded code (React.lazy), data in frameworks that support Suspense-based fetching, or the use hook reading a promise. It lets you declare loading states around parts of the tree instead of managing loading flags everywhere, and in streaming SSR it lets the server send the shell first and fill in slower parts later.

Error boundaries (class components with getDerivedStateFromError, or the react-error-boundary library) catch rendering errors in their subtree and show fallback UI; place them at the app root and around independent sections. They do not catch errors in event handlers or async code, which need try/catch and error state (or useErrorBoundary from the library). Report errors to a monitoring service in componentDidCatch or the root's error callbacks.

Classify the state first:

• Server data (fetched from an API): TanStack Query, SWR or framework loaders, which handle caching and revalidation.
• URL state (filters, pagination, selected tab): the router's search params.
• Local UI state: useState / useReducer in the component that owns it.
• Shared client state (cart, theme, auth): context with a reducer for moderate needs; Zustand, Redux Toolkit or similar when many components update it frequently or you need devtools and middleware.

Much "global state" disappears once server data and URL state are handled by the right tools.

Measure before changing anything: the React DevTools Profiler (which components render, how often, how long), the browser Performance panel, and Web Vitals (LCP, INP, CLS). Typical fixes: move state down so fewer components re-render; virtualise long lists; memoise expensive calculations and stabilise props for memoised children; split code with lazy and route-based splitting; use transitions for heavy updates; avoid layout thrashing; optimise images; and server-render content-heavy pages.

A pyramid: unit tests for pure logic (reducers, utilities); component tests with React Testing Library and Vitest or Jest that interact like a user (getByRole, user-event) and mock the network (MSW); and a few end-to-end tests with Playwright or Cypress for critical journeys such as sign-up and checkout. Test behaviour, not implementation details, so refactoring does not break tests.