Advanced React Interview Questions

Server Components render on the server (at build time or per request). Their code and any large libraries they import stay off the client bundle, and they can read databases or files directly. Because they don't run in the browser, they can't use useState, effects or event handlers; those parts go in Client Components marked with 'use client'.

You give it an action function, which receives the previous state and the form data, plus an initial state. It returns the current state (such as validation errors or a success message), a wrapped action for <form action={formAction}>, and an isPending flag for disabling the button. It replaced the earlier useFormState name.

With useOptimistic, a like or a new comment appears instantly, before the server confirms it. React shows the optimistic state while the action is pending and replaces it with the real state when the action finishes; if it fails, the optimistic value disappears. It makes apps feel fast without hand-written rollback code.

Server Components can be async and await data from a database, file system or internal API right in the component, which is one of their main benefits. They can't hold state, run effects or attach browser event handlers, because their code never reaches the browser. Put interactive pieces in Client Components and pass server data to them as props.

True. 'use client' marks a boundary: that module and everything it imports become client code. A common mistake is putting it on a high-level layout, which drags the whole subtree into the bundle. Keep the directive on small, interactive leaf components, and pass Server Components to them as children where needed.

The React Compiler analyses your components at build time and inserts memoisation where it's safe, so unchanged parts skip re-rendering without hand-written useMemo, useCallback or React.memo. It relies on your code following the rules of React, such as pure render functions and no state mutation; code that breaks them is skipped.

Hydration expects the first client render to produce the same HTML as the server. Values that differ between the two (time, random numbers, locale-dependent formatting, or window checks during render) cause a mismatch. Render a stable value first and update it in useEffect, or pass the value from the server. Browser extensions that edit the DOM can also trigger it.

Concurrent rendering lets React interrupt non-urgent work. Wrap the filter update in startTransition, or render the list from useDeferredValue(query), and the input stays responsive while React prepares the list in the background, discarding stale renders. If the list is very long, combine this with virtualisation so only visible rows are rendered.

use can unwrap a promise (suspending until it resolves) or read context, and unlike other hooks it may be called inside conditions. useDeferredValue lags a value behind for expensive renders. startTransition marks updates as interruptible. Suspense is the boundary that shows a fallback while data or code is loading.

Ten thousand rows mean tens of thousands of DOM nodes, which is slow to lay out and scroll no matter how fast React renders. Virtualisation libraries such as react-window or TanStack Virtual render only what is visible and reuse rows as you scroll, keeping the DOM small. Pagination or infinite loading are alternatives when users don't need everything at once.