React Interview Questions – Core Concepts to Advanced Patterns

It runs once, after the component first mounts, and never again. An empty dependency array tells React the effect depends on nothing that changes between renders, so there is no trigger to re-run it. Its optional cleanup function runs once, when the component unmounts. Reach for [] when the work should happen a single time — subscribing, fetching initial data, or setting up a one-off listener.

Use the updater form: setCount(c => c + 1). React passes the latest pending state into the function, so it stays correct across batching and avoids stale-closure bugs. Reading the count variable directly — setCount(count + 1) — captures the value from the current render, so calling it twice still increments only once. Whenever the next state depends on the previous, pass a function, not a value.

Three things trigger a re-render: calling the component's state setter with a new value, receiving new props, and its parent re-rendering (unless the component is memoized). Mutating a plain, non-state variable does not — React never observes that change, so it schedules no render. Only state, props, and parent renders flow through React's update mechanism.

Two rules: only call hooks at the top level of a component or custom hook, and only call them from React function components or custom hooks — never from ordinary JavaScript functions. Both follow from the same mechanism: React identifies each hook by its call order, which must stay identical on every render. That's why a hook can't sit inside an if or a for loop, where the order could change between renders.

True. Using the array index as the key ties each element's identity to its position, so when a list is reordered or filtered, React reuses the wrong DOM and component state for the wrong item — leaving stale input values or selections attached to the wrong row. A stable, unique id per item avoids this by giving each element an identity that survives reordering.

The bug is on line 4.

Both memoize across renders: useMemo caches a computed value and useCallback caches a function reference, recomputing only when their dependencies change. Use them to skip genuinely expensive recomputation or to keep a stable reference for a memoized child or an effect dependency — not as a blanket optimization, since they add overhead.

Props are inputs passed in by a parent and are read-only to the receiving component. State is data the component owns and can change over time (via its setter), triggering a re-render.

It skips re-rendering the component when its props are shallowly equal to the previous render's props. React.memo compares the incoming props and bails out of the render when nothing changed. It does not memoize internal state, and it has no effect on re-renders triggered by the component's own useState or context — those still re-render it normally.

It double-invokes renders, effects (setup→cleanup→setup), and certain other functions to expose impure logic and missing cleanup. By running these an extra time in development, Strict Mode surfaces non-idempotent renders and effects that forget to clean up. This happens in development only — production builds run everything once, so the extra invocations never affect real users.

Because dependencies can change before a request resolves, and a slow earlier response can overwrite a newer one — a race condition. If an id changes while a fetch is in flight, two requests overlap, and the slower earlier one may land last and clobber the fresh data. Cleanup that ignores the stale response, via a flag or an AbortController, prevents that. Effects can call fetch perfectly well.

React Server Components render on the server, can be async, and access server resources like files and databases directly — but they cannot use state or effects such as useState/useEffect. Their code is never shipped to the browser, which keeps bundles small but means they have no client interactivity. Anything that needs state, effects, or event handlers belongs in a client component instead.

It marks the module, and the component subtree imported from it, as a client boundary — so those components are bundled for and run in the browser, where they may use state, effects, and event handlers. Server components are the default in an RSC app, so you only add "use client" at the points where interactivity is actually required; it is not needed on every file.

React.lazy defers loading a component's code until it actually renders, and <Suspense fallback={…}> shows the fallback while that chunk downloads. Calling React.lazy(() => import('./X')) returns a component whose bundle is fetched on first render; until the dynamic import resolves, the nearest Suspense boundary displays its fallback. A lazy component must be rendered inside such a boundary.

Three statements are true: React state is the single source of truth for the value, each keystroke triggers a state update and a re-render, and the current value is always readable from state without a ref. What is false is that providing value without an onChange makes it freely editable — that combination makes the input read-only, since nothing ever updates the state driving it.