Question 1

A developer sets up a polling counter inside a useEffect using setInterval, but the state variable referenced inside the callback remains stuck at its initial render value. Explain how stale closures occur in React hooks and how you fix this using functional state updates or ref synchronization without resetting the timer on every render.

Accepted Answer

This happens because the effect callback is a closure created during whichever render the effect ran in. If you set up the interval once with an empty dependency array, the function inside setInterval permanently remembers the count variable from that first render, even though state actually updates in React's memory, the old callback never sees the new value, so it keeps reading the value it closed over.

The cleanest fix is a functional state update, which doesn't need to read the outer count at all: setCount(prev => prev + 1). React always hands the updater function the latest state, so there's no stale reference, and you don't need count in the dependency array, so the interval isn't torn down and recreated every render.

```jsx
useEffect(() => {
  const id = setInterval(() => {
    setCount(prev => prev + 1); // always fresh, no closure issue
  }, 1000);
  return () => clearInterval(id);
}, []); // safe to leave empty now
```

The alternative, a ref, is useful when you need to read other pieces of state or props inside the interval, not just increment one counter: keep a ref updated on every render (useEffect(() => { countRef.current = count; })) and read countRef.current inside the interval callback instead of count directly.

Question 2

Under React 18 Concurrent Rendering with startTransition, a custom external WebSocket store causes UI components to render inconsistent, torn state across the screen during heavy renders. How does useSyncExternalStore guarantee synchronous consistency and prevent UI tearing?

Accepted Answer

Tearing means two parts of the same screen show different snapshots of the same underlying data because the store mutated mid-render. Concurrent React can pause a render, let the browser paint other urgent updates, and resume later; if you're reading an external store with plain useState plus a manual subscribe-in-useEffect pattern, some components may have already rendered with the old value while others render with the new one after the store changes in between.

useSyncExternalStore(subscribe, getSnapshot) solves this by having React call getSnapshot again right before it commits the render. If the value returned differs from what was used during the render, React throws away that render and re-renders synchronously (bypassing time-slicing) instead of committing an inconsistent tree. This guarantees every consumer of the store commits with the exact same snapshot in one atomic update.

```jsx
function useWsMessages() {
  return useSyncExternalStore(
    (callback) => { ws.addEventListener('message', callback); return () => ws.removeEventListener('message', callback); },
    () => wsStore.getSnapshot(),
    () => wsStore.getServerSnapshot()
  );
}
```

This is why library authors (Redux, Zustand, Jotai) all moved their React bindings onto useSyncExternalStore for React 18: it's the only hook that's contract-guaranteed to be tear-free under concurrent rendering, whereas hand-rolled useEffect subscriptions are not.

Question 3

A user rapidly switches between tabs in a dashboard, firing asynchronous network requests for each tab. Due to varying server latencies, older responses resolve after newer ones and overwrite the current view. Design a custom useFetch hook using AbortController cleanup within useEffect to cancel in-flight requests and prevent race conditions.

Accepted Answer

The race happens because nothing tells the earlier fetch to stop mattering once a newer one starts — both promises resolve independently and whichever resolves last wins, even if it's stale. The fix is to actually cancel the outdated request rather than just ignoring its result, using AbortController tied to the effect's cleanup function.

Each time the effect re-runs (tab changes), React first calls the previous effect's cleanup, which aborts the in-flight request for the old tab before starting the fetch for the new one. The aborted fetch's promise rejects with an AbortError, which we can safely swallow.

```jsx
function useFetch(url) {
  const [data, setData] = useState(null);
  const [error, setError] = useState(null);

useEffect(() => {
    const controller = new AbortController();
    setData(null);
    fetch(url, { signal: controller.signal })
      .then(res => res.json())
      .then(setData)
      .catch(err => {
        if (err.name !== 'AbortError') setError(err);
      });
    return () => controller.abort();
  }, [url]);

return { data, error };
}
```

Because the cleanup runs synchronously before the new fetch starts, there's never a window where two requests for different tabs are both racing toward the same state setter.

Question 4

You are building a social media feed where 'liking' a post should reflect instantly in the UI while sending a mutation request to the backend. How do you implement useOptimistic alongside React Server Actions to handle optimistic increments and automatic state rollback when the mutation fails?

Accepted Answer

useOptimistic(state, updateFn) takes your real, server-confirmed state and returns a derived optimistic value plus a function to apply a temporary change to it. You call that setter synchronously inside the same event handler that kicks off the server action, so the UI updates instantly, before the network round-trip even starts. Crucially, the optimistic value is always computed from the current real state — it isn't a separate piece of state you have to manually reset. So if the server action throws or the promise rejects, React simply re-renders using the unmodified real state, and the optimistic UI change disappears on its own without any explicit rollback code. ```jsx function LikeButton({ post, likeAction }) { const [optimisticLikes, addOptimisticLike] = useOptimistic( post.likes, (current) => current + 1 ); async function handleLike() { addOptimisticLike(); await likeAction(post.id); // Server Action; throws on failure } return ; } ``` If likeAction succeeds, the server-revalidated post.likes eventually matches what the optimistic value already showed, so there's no visible flicker; if it fails, the button reverts to the real like count once the action's promise rejects and React re-renders.

Question 5

A multi-step onboarding wizard relies on seven independent useState hooks, causing erratic intermediate states when multiple state setters are called across asynchronous validation steps. How would you refactor this state layer into a deterministic state machine using useReducer?

Accepted Answer

With seven independent useState calls, nothing stops you from ending up in an invalid combination — e.g. step advancing to 3 while validationError from step 2 is still set, because each setter fires independently and async validation can resolve in any order. There's no single place that enforces which combinations of values are actually valid.

useReducer fixes this by collapsing all of that into one state object updated only through a single dispatch function, with a switch statement that defines exactly what each action is allowed to change. That switch becomes the one place your state-transition rules live, instead of being scattered implicitly across multiple setState calls in different handlers.

```jsx
function wizardReducer(state, action) {
  switch (action.type) {
    case 'NEXT_STEP':
      return state.error ? state : { ...state, step: state.step + 1, error: null };
    case 'VALIDATION_ERROR':
      return { ...state, error: action.error };
    case 'SET_FIELD':
      return { ...state, fields: { ...state.fields, [action.field]: action.value }, error: null };
    default:
      return state;
  }
}

const [state, dispatch] = useReducer(wizardReducer, { step: 1, fields: {}, error: null });
```

Because every transition goes through the reducer, an async validation result that resolves late just dispatches an action — the reducer decides what's valid given the CURRENT state at that moment, so you can't accidentally advance past a step with an unresolved error.

Question 6

A heavy child component wrapped in React.memo continues to re-render on every parent update. Profiling reveals that inline object literals and arrow function callbacks are passed as props. How do you use useCallback and useMemo properly to maintain referential equality without introducing unnecessary dependency overhead?

Accepted Answer

React.memo does a shallow comparison of props between renders — it checks if each prop is === to the previous one. An inline arrow function or object literal (`onSave={() => save(id)}`, `style={{color: 'red'}}`) is a brand new reference every single render, even though its contents are identical, so the shallow comparison always sees a 'change' and memo can't skip the re-render.

useCallback(fn, deps) keeps the same function reference across renders as long as the dependencies haven't changed, and useMemo(() => value, deps) does the same for a computed object or array. Wrapping the exact props being passed down in these hooks restores referential stability so React.memo's comparison actually succeeds.

```jsx
function Parent({ id }) {
  const handleSave = useCallback(() => save(id), [id]);
  const style = useMemo(() => ({ color: 'red' }), []);
  return <HeavyChild onSave={handleSave} style={style} />;
}
const HeavyChild = React.memo(function HeavyChild({ onSave, style }) { /* ... */ });
```

The important caveat: only memoize props that are actually passed to a memoized child (or used as another hook's dependency) — wrapping every handler in useCallback 'just in case' adds dependency-array bookkeeping and a small memory cost for no benefit if nothing downstream cares about reference stability.

Question 7

A real-time search input filters a list of 10,000 data rows, causing keystroke latency and sluggish typing. Compare using useTransition to mark the state update as non-urgent versus using useDeferredValue on the query string, explaining how the reconciliation priorities differ.

Accepted Answer

Both let React interrupt a slow, low-priority render to keep the input responsive, but they attach the 'this can wait' label to different things. useTransition wraps the actual setState call at the point you own it: `startTransition(() => setQuery(text))`. You're explicitly telling React 'the update this setter causes is non-urgent,' which is natural when you control the event handler directly.

useDeferredValue instead wraps a value you've already received: `const deferredQuery = useDeferredValue(query)`. You don't touch the setter at all — the input still updates query urgently and re-renders instantly, but the expensive list below reads deferredQuery, which 'lags behind' during heavy renders and catches up once React has spare time. This is the right tool when you receive a value as a prop and don't control where it's set (e.g. a search box owned by a parent).

```jsx
// useTransition: you own the setter
const [isPending, startTransition] = useTransition();
function handleChange(e) {
  setInput(e.target.value); // urgent, updates instantly
  startTransition(() => setQuery(e.target.value)); // non-urgent
}

// useDeferredValue: you only have the value
const deferredQuery = useDeferredValue(query);
const results = useMemo(() => filterRows(deferredQuery), [deferredQuery]);
```

In both cases React still does the full expensive re-render eventually, it just prioritizes the input's own re-render first and can interrupt or discard the deferred one if the user keeps typing.

Question 8

An application uses a single global React Context containing both authentication data (updated rarely) and theme/cursor position data (updated at 60fps), causing the entire component tree to re-render continuously. How do you resolve this context cascade by splitting contexts, using selector wrappers, or memoizing consumer subtrees?

Accepted Answer

Every consumer of a Context re-renders whenever the Provider's value prop changes identity, regardless of whether that consumer actually reads the part of the value that changed. Bundling fast-changing cursor coordinates into the same object as rarely-changing auth data means the auth-only consumers re-render 60 times a second along with everyone else. The direct fix is splitting into separate contexts — AuthContext and CursorContext — each with its own Provider, so a component that only calls useContext(AuthContext) is structurally incapable of re-rendering when cursor position changes, because it never subscribed to that context at all. ```jsx ``` If you genuinely need one provider for API convenience, an alternative is a selector-based store (Zustand, Jotai, or use-context-selector) where subscribers declare exactly which slice they read and only re-render when that slice changes, rather than the whole context value. Wrapping expensive subtrees in React.memo also helps as a second layer of defense, but it doesn't fix the root cause — the component still re-renders and just skips re-rendering its children if props are unchanged.

Question 9

You implement a virtualized list for a chat feed where messages have dynamic, unknown heights until rendered. Users experience scroll jumping and layout jitter during rapid scrolling. How do you configure dynamic height measurement caches and estimated item sizing in virtualization libraries to maintain scroll stability?

Accepted Answer

Virtualizers only render a small window of items and compute scroll-container height/offsets mathematically from each item's size, so they need a size for every item — including ones off-screen that haven't rendered yet. With genuinely dynamic heights (text wrapping, images, emoji reactions), the library has to guess before it knows the real value, and correcting that guess after the fact is exactly what causes visible jumps. The fix has two parts. First, give the virtualizer a reasonable estimateSize function based on typical content (e.g. average message height) so the initial guess is close, minimizing the size of any correction. Second, use the library's dynamic measurement mode: after an item actually renders, measure its real height (react-virtual's measureElement via a ResizeObserver-backed ref callback) and write that into a per-index cache, then have the virtualizer recompute offsets for everything below using the cached real values instead of the estimate. ```jsx const rowVirtualizer = useVirtualizer({ count: messages.length, getScrollElement: () => parentRef.current, estimateSize: () => 72, // average message height, tuned from real data }); // per row:

{message.text}

``` For scroll stability specifically during rapid scrolling, anchoring the scroll position to a stable item (rather than a raw pixel offset) while measurements settle avoids the classic 'jump to the wrong spot' bug when several off-screen items get re-measured at once.

Question 10

A team notices their client-side bundle size increased significantly after migrating to React Server Components (RSC) because developers placed 'use client' directives at top-level layout wrappers. How do you audit component trees to push client boundaries down to leaf nodes and pass server components as children slots?

Accepted Answer

'use client' doesn't just mark the one file it's written in — it marks the module boundary, and every component that file imports and renders directly becomes part of the client bundle too. Put it on a top-level Layout, and everything Layout renders inline (even purely presentational, non-interactive pieces) gets pulled into client JS, defeating the whole point of RSC shipping less JavaScript. The fix is to find the actual interactive leaf — the dropdown, the like button, the tab switcher — and put 'use client' only on that small component, not on the layout that contains it. Everything else in the tree stays a Server Component by default and never ships to the browser. The trick for keeping server-rendered content inside a client component without importing it there is the children slot pattern: the client component accepts children as a prop instead of importing and rendering a server component directly (client files can't import server components, but they CAN render whatever is passed to them as children/props from a parent server component). ```jsx // ClientDropdown.jsx 'use client' function ClientDropdown({ children }) { const [open, setOpen] = useState(false); return

setOpen(!open)}>{open && children}

; } // Page.jsx (Server Component) {/* stays server-only */} ``` Auditing for this means grepping for 'use client' at high-level layout/page files first, since that's where the blast radius is largest, and checking whether the directive could instead sit on a smaller child.

Question 11

Running a component integration test with React Testing Library passes, but prints the warning: Warning: An update to Component inside a test was not wrapped in act(...). Walk through the root cause of this warning and how to properly resolve it using waitFor or findByRole rather than manually sprinkling act() calls.

Accepted Answer

This warning fires when a state update happens after your test's synchronous assertions have already run — typically because something async (a resolved fetch promise, a timer, a microtask) updates state slightly later than the test expected. React can't guarantee the DOM reflects that update at the moment you assert, and manually calling act() around the render doesn't help because the update genuinely happens later, outside that act() call's scope.

The wrong instinct is to sprinkle extra `await act(async () => {})` calls hoping to 'catch' the update — that's fragile because it doesn't actually wait for anything specific, it just yields the event loop once and hopes it's enough.

The correct fix is to make the test itself wait for the real condition using RTL's async queries, which internally poll and are already wrapped in act for you:

```jsx
// instead of asserting immediately after render:
await waitFor(() => expect(screen.getByText('Loaded')).toBeInTheDocument());
// or, equivalent and more idiomatic for elements that will appear:
const el = await screen.findByRole('heading', { name: 'Loaded' });
```

Either of these retries the assertion until it passes or times out, so the test naturally waits exactly as long as needed for the async update to land, and the warning disappears because the update now happens inside the polling/act-wrapped window RTL manages.

Question 12

Your test suite frequently breaks when refactoring internal component fetch calls because tests rely on jest.spyOn(global, 'fetch'). How do you transition component testing to Mock Service Worker (MSW) to intercept requests at the network layer and test realistic loading, success, and HTTP 500 error boundaries?

Accepted Answer

Spying on global.fetch couples your tests to HOW the component fetches — exact call arguments, call count, whether it's fetch vs axios vs a wrapped client. Refactor the internal implementation (switch libraries, change the URL builder, add a retry wrapper) and the spy assertions break even though the component's actual behavior toward the user hasn't changed at all.

MSW intercepts at the network layer instead — it registers handlers for specific URLs/methods and returns responses regardless of what HTTP client the component uses under the hood, so tests only care about what request goes out and what response comes back, not how the fetch call is constructed.

```js
// handlers.js
export const handlers = [
  http.get('/api/user/:id', () => HttpResponse.json({ id: 1, name: 'Ana' })),
];

// in a specific test, override for the error case
server.use(
  http.get('/api/user/:id', () => new HttpResponse(null, { status: 500 }))
);
```

With the base handlers set up once in test setup (server.listen() in a global beforeAll), most tests get realistic success responses for free, and individual tests use server.use() to override just the endpoint they want to fail, letting you assert the component's actual loading skeleton, rendered data, and error-boundary fallback UI — all without touching the component's internals.

Question 13

How do you test a custom useLocalStorage hook using @testing-library/react's renderHook, verifying that value mutations synchronize with window.localStorage, prop updates trigger re-evaluations via rerender(), and window event listeners clean up on unmount()?

Accepted Answer

renderHook(() => useLocalStorage('key', 'default')) runs the hook outside of any component you have to build by hand, and returns a result object whose .current always holds the hook's latest return value, plus rerender() and unmount() functions to drive its lifecycle in the test.

To verify the setter writes through to localStorage, call the setter inside act() (state updates need to be wrapped so React flushes them before you assert), then check the real storage:

```jsx
const { result, rerender, unmount } = renderHook(
  ({ key }) => useLocalStorage(key, 'default'),
  { initialProps: { key: 'theme' } }
);

act(() => result.current[1]('dark'));
expect(window.localStorage.getItem('theme')).toBe(JSON.stringify('dark'));

rerender({ key: 'otherKey' }); // simulates the hook receiving new props
expect(result.current[0]).toBe('default'); // re-read against the new key
```

For cleanup, spy on addEventListener/removeEventListener before mounting, then call unmount() and assert removeEventListener was called with the same handler reference addEventListener registered — that confirms the hook's useEffect cleanup function actually runs and doesn't leak a listener attached to a component instance that no longer exists.

Question 14

You are writing integration tests for a page wrapped in a Suspense boundary with a Skeleton fallback that loads data via concurrent promises. How do you construct tests that explicitly assert the initial fallback state, advance mocked timers or pending promises, and verify settled DOM elements without flaky timing races?

Accepted Answer

The reliable pattern is to control the promise yourself rather than trusting real timing: create a promise whose resolve function you hold onto, feed it into whatever the component suspends on (a mocked fetch or data-fetching wrapper), then decide exactly when to resolve it inside the test. ```jsx let resolveFetch; const pending = new Promise((res) => { resolveFetch = res; }); vi.mocked(fetchUser).mockReturnValue(pending); render(}>); expect(screen.getByTestId('skeleton')).toBeInTheDocument(); // assert fallback first await act(async () => { resolveFetch({ name: 'Ana' }); await pending; }); expect(await screen.findByText('Ana')).toBeInTheDocument(); ``` The reason this avoids flakiness is that nothing depends on wall-clock timers or arbitrary waitFor polling intervals racing against real async resolution — the test explicitly drives when the promise settles, and wrapping the resolution in `act` plus awaiting the promise itself ensures React has actually flushed the resulting re-render before you assert the settled DOM. Using fake timers here is usually the wrong tool since Suspense resolution is tied to microtask/promise scheduling, not to setTimeout-based timers, so advancing fake timers won't reliably move a Suspense boundary forward unless the underlying data source itself uses timers.

Question 15

Design an accessible, highly customizable Tabs component system composed of Tabs, TabList, Tab, and TabPanels sub-components. How do you use React Context and React.Children to share active tab state and keyboard navigation logic implicitly without prop drilling?

Accepted Answer

The Tabs root component owns the actual state (activeIndex, setActiveIndex) and exposes it through a Context.Provider, so every descendant — no matter how deeply nested inside TabList or TabPanels — can read and update the active tab without any of the intermediate components needing to know about it or forward props manually. ```jsx const TabsContext = createContext(null); function Tabs({ children, defaultIndex = 0 }) { const [activeIndex, setActiveIndex] = useState(defaultIndex); return (

{children}

); } function Tab({ index, children }) { const { activeIndex, setActiveIndex } = useContext(TabsContext); return ( ); } function TabPanel({ index, children }) { const { activeIndex } = useContext(TabsContext); return activeIndex === index ?

{children}

: null; } ``` This lets a consumer write plain declarative JSX — `` — while state, ARIA roles, and arrow-key navigation are all handled implicitly. It's the same pattern behind libraries like Radix and Headless UI, and it beats prop drilling because adding a new sub-component (say, a TabBadge) never requires threading activeIndex through every layer in between.

Question 16

A runtime JavaScript exception inside a complex data chart crashes the entire single-page application into a blank white screen. How do you implement granular Class Error Boundaries (getDerivedStateFromError, componentDidCatch) with reset keys to isolate component failures and allow localized user retries?

Accepted Answer

Error boundaries only exist as class components today because getDerivedStateFromError and componentDidCatch are lifecycle methods with no hook equivalent; a single boundary at the app root catches everything, but that means ANY component's crash takes down the whole page, which is exactly the failure mode described here. The fix is placing a boundary around each independently-failable section — wrap just the chart, not the whole dashboard — so a crash there only replaces that one widget with a fallback, leaving the rest of the page usable. ```jsx class ErrorBoundary extends React.Component { state = { hasError: false }; static getDerivedStateFromError() { return { hasError: true }; } componentDidCatch(error, info) { logErrorToService(error, info); } componentDidUpdate(prevProps) { if (this.state.hasError && prevProps.resetKey !== this.props.resetKey) { this.setState({ hasError: false }); // reset when resetKey changes } } render() { return this.state.hasError ? this.props.fallback : this.props.children; } } }> ``` The resetKeys pattern (as popularized by the react-error-boundary library) lets the boundary clear its errored state automatically whenever some value that indicates 'the underlying situation changed' changes — e.g. the user picked a different chart or refetched data — without requiring a full page reload just to retry.

Question 17

You are building a shared design system Button component that can dynamically render as an anchor tag, a button tag, or a custom Next.js Link via an 'as' prop. How do you implement TypeScript polymorphic component typing using React.ComponentPropsWithRef to guarantee strict prop and ref type safety?

Accepted Answer

A polymorphic component needs its prop types to change depending on what element/component is passed via `as` — an anchor needs `href`, a button doesn't, and a custom Link component has its own prop set entirely. Hardcoding one prop union loses type safety for whichever variant isn't hardcoded. The standard approach is a generic type parameter constrained to React.ElementType, combined with React.ComponentPropsWithRef to pull in exactly the right props (including a correctly-typed ref) for whatever C ends up being: ```tsx type PolymorphicProps = { as?: C; children?: React.ReactNode; } & Omit, 'as' | 'children'>; function Button({ as, ...rest }: PolymorphicProps) { const Component = as || 'button'; return ; } // usage — each variant gets correctly typed props: // errors, 'button' has no href ``` ComponentPropsWithRef (rather than plain ComponentProps) matters specifically because it also types the ref correctly for whichever element is rendered — an `` ref is an HTMLAnchorElement, a `

Question 18

Three autonomous teams build different sections of an enterprise dashboard using Webpack Module Federation. How do you configure shared dependencies (like react, react-dom) with singleton: true and requiredVersion to avoid loading multiple React runtime instances while isolating router states?

Accepted Answer

Without sharing configuration, each independently-built remote bundles its own copy of react and react-dom. Multiple React copies break in subtle ways: a Context.Provider created by one copy's React instance is invisible to a Consumer created by another copy (each copy has its own internal Context implementation), and calling hooks across a copy boundary throws 'Invalid hook call' because each copy has its own internal dispatcher tracking the currently-rendering component.

`shared: { react: { singleton: true, requiredVersion: '^18.0.0' }, 'react-dom': { singleton: true, requiredVersion: '^18.0.0' } }` in ModuleFederationPlugin tells Webpack that no matter how many remotes request react, only ONE instance should ever be loaded and shared across the whole federated application at runtime. requiredVersion enforces that all participants are actually compatible with that shared version — if a remote demands an incompatible major version, Module Federation warns (or, depending on config, falls back to loading its own eager copy, which reintroduces the duplicate-instance problem, so mismatches need to be caught in CI, not just at runtime).

```js
new ModuleFederationPlugin({
  shared: {
    react: { singleton: true, requiredVersion: '^18.2.0' },
    'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
  },
});
```

Router state isolation is a separate concern from the React singleton — typically solved by giving each micro-frontend its own basename/nested route subtree (so React Router's own singleton instance manages one coherent route tree) rather than each remote running an independent, unaware router that could double-handle the same URL.

Question 19

Why is separating UI state and keyboard accessibility logic into 'Headless' custom hooks (e.g., useDropdown) preferred over monolithic UI component libraries when building an enterprise design system across web and mobile (React Native) targets?

Accepted Answer

A monolithic UI library component bundles three things together that don't actually need to travel as one unit: the behavior (open/close state, which item is focused, keyboard handling), the accessibility wiring (ARIA roles/attributes), and the markup/styling. That coupling is fine until you need the same behavior rendered differently — say, a web app using divs and CSS versus a React Native app using View and Pressable, which don't share a DOM or ARIA at all.

A headless hook like useDropdown extracts just the behavior and accessibility logic — open state, keyboard navigation rules, which element should currently be focused — and returns plain values and handler functions, leaving 100% of the actual rendering to the consumer:

```jsx
function useDropdown() {
  const [open, setOpen] = useState(false);
  const [activeIndex, setActiveIndex] = useState(0);
  const onKeyDown = (e) => {
    if (e.key === 'ArrowDown') setActiveIndex(i => i + 1);
    if (e.key === 'Escape') setOpen(false);
  };
  return { open, setOpen, activeIndex, onKeyDown };
}

// Web:  renders <ul role="listbox"> with divs
// Native: renders a FlatList with Pressable rows
// Both call the exact same useDropdown hook
```

Beyond cross-platform reuse, this also makes the logic trivially unit-testable without a DOM (you're just asserting on returned values from a hook), and it means restyling the design system doesn't risk touching behavior at all, since the two are structurally separate files.

Question 20

What is the Virtual DOM and how does React use it to update the UI efficiently?

Accepted Answer

The Virtual DOM is a lightweight JavaScript object tree that mirrors the structure of the real DOM but is much cheaper to create and compare, since it's just plain objects in memory rather than actual browser rendering primitives. When state changes, React builds a brand new virtual tree describing what the UI should look like now.

React then diffs (reconciles) this new tree against the previous one to figure out the minimal set of actual DOM operations needed, and applies only those changes in a single batch — rather than re-rendering everything from scratch, which would be slow because real DOM writes can trigger expensive browser layout and paint work.

For example, updating the text of one `<li>` inside a 1,000-item list causes React to patch just that single text node in the real DOM; the other 999 list items are left completely untouched, even though React internally recomputed a full virtual tree to figure that out.

Question 21

What is the difference between state and props in React?

Accepted Answer

Props are data passed INTO a component from its parent — they're read-only from the receiving component's point of view, similar to arguments passed into a function, and a component should never modify its own props directly. State is data a component manages internally, using useState or useReducer, and it can change over time in response to user interaction or other events, triggering a re-render whenever it's updated. ```jsx function Parent() { return ; // 'initialValue' is a prop } function Counter({ initialValue }) { const [count, setCount] = useState(initialValue); // 'count' is state return ; } ``` The practical distinction matters for data flow: props always flow one way, top-down, so a child can't change what its parent passed it (it can only ask the parent to change it, usually via a callback prop) — whereas state is entirely local to whichever component declared it, unless deliberately lifted up to a shared parent.

Question 22

Why do list items in React need a unique 'key' prop, and what goes wrong if you use the array index as the key?

Accepted Answer

React uses keys to match elements in a list between renders during reconciliation — it's how React decides 'this is the same logical item as before, just update it' versus 'this is a new item, mount it fresh.' Without stable keys, or with keys that don't actually identify the underlying data, React falls back to matching by position, which silently breaks when the list's order or membership changes. Using the array index as a key is exactly this trap: if you insert an item at the start of the list, every existing item shifts down one index, so React thinks index 0's content changed (rather than realizing a new item was inserted before everything else), and reassigns each existing component instance to the wrong underlying data. ```jsx // Bug: typing in the first input, then deleting item 0, moves your typed // text to what is now displayed as a DIFFERENT todo, because the input's // component instance stayed tied to index 0, not to the todo it actually held. todos.map((todo, index) => ) // Fix: use a stable id from the data itself todos.map((todo) => ) ``` The fix is always to key off something stable and unique to the actual data (a database id, a UUID) rather than the item's position in the array, so React can correctly track identity across insertions, deletions, and reorders.

Question 23

What is the difference between controlled and uncontrolled components in React forms?

Accepted Answer

A controlled component has its value driven entirely by React state — you pass `value` and update it via `onChange`, so React is the single source of truth and the DOM input's displayed value is always whatever state says it is. This makes per-keystroke validation, formatting, or conditionally disabling a submit button trivial, since you have the current value on every render. An uncontrolled component lets the DOM manage its own value internally; React only reads it when needed, typically via a ref, rather than re-rendering on every keystroke. ```jsx // Controlled function ControlledInput() { const [value, setValue] = useState(''); return setValue(e.target.value)} />; } // Uncontrolled function UncontrolledInput() { const ref = useRef(); const handleSubmit = () => console.log(ref.current.value); return ; } ``` Uncontrolled inputs avoid a re-render on every keystroke, which can matter for very large forms, and they're the only real option for ``, since you can't set a file input's value programmatically. Controlled inputs are the more common default because most forms need live validation or need to keep the input in sync with other UI state.

Question 24

How does the useEffect dependency array control when an effect runs, and what happens if you get it wrong?

Accepted Answer

Leaving off the dependency array entirely makes the effect run after every single render, which is rarely what you want since it usually re-triggers side effects (network calls, subscriptions) unnecessarily. Passing an empty array `[]` makes it run exactly once, right after the initial mount, and never again. Passing an array with specific values makes it re-run whenever any of those values changes between renders (compared by reference for objects/arrays, by value for primitives).

```jsx
useEffect(() => {
  fetchUser(userId).then(setUser);
}, [userId]); // re-fetches whenever userId changes
```

The common mistake is omitting a value the effect actually reads (say, fetching with userId but leaving the array as `[]`) — this passes the linter's radar only if you also disable the exhaustive-deps rule, and it creates a stale closure: the effect keeps using whatever userId was true at mount time forever, even after the real userId prop changes, because it never re-runs to pick up the new value.

Question 25

What is prop drilling, and how can Context API or component composition help avoid it?

Accepted Answer

Prop drilling is passing a piece of data through several layers of components that don't themselves use it, purely so it reaches some deeply nested descendant that does. Each intermediate component ends up with props in its signature it has no business caring about, and adding a new consumer deep in the tree means threading the prop through every layer again. Context API solves this directly: a Provider exposes a value, and any descendant — no matter how deep — reads it via useContext without any of the components in between needing to know it exists. ```jsx const ThemeContext = createContext('light'); function App() { return ; } function Layout() { return ; } // doesn't touch theme at all function Sidebar() { const theme = useContext(ThemeContext); return

; } ``` Component composition is the other tool, useful when you don't even need shared global state: instead of passing raw data down through Layout to reach Sidebar, render Sidebar (already fully configured) directly in App and pass it into Layout as `children` — Layout then never needs to know about theme at all, because it's just rendering whatever was handed to it.

Question 26

What are Higher-Order Components (HOCs), and how do they differ from custom hooks for sharing logic between components?

Accepted Answer

A Higher-Order Component is a function that takes a component and returns a new component, typically injecting extra props or wrapping it with additional behavior — `withAuth(ProfilePage)` returns a new component that checks authentication and renders ProfilePage with a `user` prop added. This was the primary code-reuse pattern before hooks existed. A custom hook instead returns values directly from a function called inside the component's own body: `const { user } = useAuth();`. There's no extra wrapping component in the tree, no prop-name collisions between two HOCs that both want to inject a `data` prop, and no need to manually forward refs through the wrapper, which HOCs historically required forwardRef gymnastics for. ```jsx // HOC function withAuth(Component) { return function Wrapped(props) { const user = useCurrentUser(); return ; }; } // Custom hook equivalent function ProfilePage() { const user = useAuth(); return

{user.name}

; } ``` Most cross-cutting logic sharing has moved to custom hooks since they compose more cleanly (call several hooks side by side with no nesting), but HOCs still show up for genuinely wrapping rendered output (e.g. a layout HOC) or in codebases still using class components, where hooks aren't available.

Question 27

What is the difference between useMemo and useCallback?

Accepted Answer

useMemo(fn, deps) memoizes the RETURN VALUE of the function you pass it — it recomputes that value only when a dependency changes, otherwise it reuses the cached result. It's typically used for expensive computations or for creating an object/array that needs a stable reference across renders.

useCallback(fn, deps) memoizes the FUNCTION ITSELF, returning the same function reference across renders as long as dependencies are unchanged. Under the hood, `useCallback(fn, deps)` is exactly equivalent to `useMemo(() => fn, deps)` — useCallback is really just useMemo specialized for the case where the 'value' you want to cache happens to be a function.

```jsx
const expensiveResult = useMemo(() => computeTotals(items), [items]); // cached value
const handleClick = useCallback(() => onSelect(id), [id]); // cached function reference
```

The practical rule of thumb: reach for useCallback when you're passing a function down as a prop (especially to a React.memo'd child, or as another hook's dependency) and want to avoid it being a new reference every render; reach for useMemo when the thing you're caching is a computed value or object, not a function.

Question 28

What is React.StrictMode, and why does it intentionally double-invoke certain functions in development?

Accepted Answer

StrictMode is a wrapper component that doesn't render any visible UI itself but opts its subtree into extra development-only checks designed to surface bugs before they become hard-to-diagnose production issues. It has no effect in production builds — it's purely a dev-time safety net.

One of its checks is intentionally calling certain functions twice: component render functions, and (in React 18+) effect setup/cleanup (mount → cleanup → mount again). The goal is to catch impure code — a render function that mutates something outside itself, or an effect whose cleanup doesn't properly undo everything the setup did — since a component that isn't safe to call twice in a row usually has a real bug that would also bite you under React's actual concurrent rendering or in a future feature like fast refresh.

```jsx
function Widget() {
  console.log('rendering'); // logs twice per actual commit under StrictMode in dev
  useEffect(() => {
    const id = setInterval(tick, 1000);
    return () => clearInterval(id); // if this is missing/wrong, StrictMode's double mount exposes a leak fast
  }, []);
}
```

Seeing double console logs or double network calls in development under StrictMode is expected behavior, not a bug in React itself — it's specifically trying to make an existing latent bug in your code visible sooner.

Question 29

What is the difference between useEffect and useLayoutEffect, and when should you reach for useLayoutEffect?

Accepted Answer

useEffect runs asynchronously, AFTER the browser has already painted the updated screen to the user. useLayoutEffect runs synchronously, right after React has applied DOM mutations but BEFORE the browser paints — meaning it can block the paint until it finishes.

This timing difference matters specifically when you need to measure something in the DOM and then synchronously adjust layout before the user sees anything, to avoid a visible flash of incorrect positioning. A classic example is a tooltip that needs to measure its own size to decide whether it should flip above or below its target.

```jsx
useLayoutEffect(() => {
  const rect = tooltipRef.current.getBoundingClientRect();
  if (rect.bottom > window.innerHeight) {
    setPlacement('top'); // adjust BEFORE paint, so no flicker
  }
}, []);
```

Using useLayoutEffect for everything is a mistake though — since it blocks paint, an expensive useLayoutEffect makes the whole page feel less responsive. It should be reserved for genuine DOM-measurement-and-adjust cases; anything else (data fetching, subscriptions, logging) belongs in the ordinary, non-blocking useEffect.

Question 30

What is code-splitting in React, and how do React.lazy and Suspense implement it?

Accepted Answer

Code-splitting means breaking your JavaScript bundle into smaller chunks that load on demand instead of shipping the entire application's code up front. This matters because a feature a user might never touch — an admin panel, a rarely-opened modal, a settings page — shouldn't slow down the initial page load for everyone. React.lazy(() => import('./Modal')) wraps a dynamic `import()` so React only requests that chunk over the network the first time the component is actually rendered, rather than at initial bundle load. Because that import is asynchronous, you have to wrap it in a `` boundary, which shows a fallback (a spinner, a skeleton) while the chunk is downloading. ```jsx const SettingsPanel = React.lazy(() => import('./SettingsPanel')); function App() { return ( }> {showSettings && } ); } ``` The most common places to apply this are route-based splits (each page/route is its own chunk, loaded only when navigated to) and rarely-used heavy features, since those give the biggest reduction in initial bundle size for the least added complexity.

Question 31

What are React Portals, and what problem do they solve?

Accepted Answer

ReactDOM.createPortal(children, domNode) lets you render a component's output into a DOM node that lives somewhere else in the document — outside the parent component's own DOM hierarchy — while the component stays logically inside the React tree in every other way: context still flows through it normally, and events bubbling up from inside the portal are caught by React event handlers on its logical ancestors, not just its DOM ancestors. This matters for UI like modals, tooltips, and dropdown menus, which often need to visually escape a parent container that has `overflow: hidden` or a constrained `z-index` stacking context — rendering the modal as a normal DOM child would get clipped or hidden behind other elements no matter what CSS you apply. ```jsx function Modal({ children }) { return ReactDOM.createPortal(

{children}

, document.getElementById('modal-root') // a div outside the app's main container, e.g. a direct child of body ); } ``` Because a click inside the portal still bubbles up through React's synthetic event system to the component that rendered it (not just to whatever the DOM node's real parent happens to be), event handlers like onClick-outside-to-close work exactly as if the modal were rendered in place, even though visually it lives elsewhere in the page.

Question 32

What is the relationship between forwardRef and useImperativeHandle?

Accepted Answer

Function components don't expose a ref to their underlying DOM node or internal instance by default — attaching `ref={myRef}` directly to a custom function component just produces a warning, because there's nothing for the ref to attach to unless the component opts in. forwardRef((props, ref) => ...) is how a component opts in, receiving the ref as a second argument it can then attach to whatever DOM node it wants to expose.

useImperativeHandle goes a step further: instead of exposing the raw DOM node, it lets the component define a completely custom object as what the ref points to — useful when you want to expose a curated, minimal API (focus(), reset(), scrollToTop()) rather than the entire underlying DOM element and its full surface area.

```jsx
const FancyInput = forwardRef((props, ref) => {
  const inputRef = useRef();
  useImperativeHandle(ref, () => ({
    focus: () => inputRef.current.focus(),
    clear: () => { inputRef.current.value = ''; },
  }));
  return <input ref={inputRef} {...props} />;
});

// parent: fancyInputRef.current.focus() works, but fancyInputRef.current.value does not
```

This combination is common for design-system components where you want parents to be able to imperatively trigger specific behaviors without leaking internal DOM structure they could otherwise mutate directly and unpredictably.

Question 33

What are the Rules of Hooks, and why must hooks always be called in the same order on every render?

Accepted Answer

The two rules are: only call hooks at the top level of a function component or custom hook (never inside loops, conditionals, or nested functions), and only call hooks from React function components or other custom hooks (never from regular JS functions or class components).

The reason is mechanical: React doesn't track hooks by name, it tracks them by CALL ORDER, storing each hook's state in a linked list attached to that component's fiber. On each render, React walks that list assuming the Nth useState call this render corresponds to the same Nth useState call from last render. If a hook call becomes conditional, the Nth call might now be a different hook entirely, so React attaches the wrong stored state to it.

```jsx
// Broken: if `condition` is sometimes true, sometimes false, the useState
// call for `theme` shifts position, silently corrupting subsequent hooks' state
if (condition) {
  const [theme, setTheme] = useState('light');
}
const [count, setCount] = useState(0);
```

This is also why the pattern is banned even when a loop always runs a fixed number of times today — the guarantee only holds if it's structurally impossible for the count to differ, not just true by coincidence at the moment the code was written.

Question 34

What is reconciliation, and what heuristics does React's diffing algorithm rely on to stay close to O(n) instead of the theoretically correct O(n³) tree-diff?

Accepted Answer

Reconciliation is the process of comparing the new virtual DOM tree against the previous one to figure out the minimal set of real DOM changes needed. A fully general tree-diffing algorithm that considers every possible way one tree could transform into another is O(n³) in the number of nodes, which is far too slow to run on every state update in a UI. React makes this tractable with two pragmatic heuristics that trade some theoretical correctness for massive real-world speed. First, elements of different types produce fundamentally different trees — if a `

` becomes a `` at the same position, React doesn't try to diff their children at all; it tears down the whole old subtree (running cleanup/unmount) and builds the new one from scratch. Second, for lists of sibling elements, `key` gives React a stable identity hint so it matches elements across renders by key rather than by index position — without keys, reordering a list looks to React like every item at every position changed. ```jsx // Without keys, reordering [A, B, C] to [C, A, B] looks like // every position's content changed. With stable keys, React sees // the same three elements just moved, and reuses their instances. items.map(item => ) ``` These heuristics work well in practice because real UIs rarely restructure wildly between renders — most updates change content within an otherwise stable tree shape, which is exactly the case these two rules optimize for.

Question 35

What is hydration in server-rendered React apps, and what causes a hydration mismatch error?

Accepted Answer

Hydration is the process where React takes server-rendered static HTML that's already in the page and 'attaches' to it on the client — reusing the existing DOM nodes and wiring up event listeners and internal state, rather than tearing everything down and re-rendering from scratch. This is what makes server-rendered pages both fast to first paint and interactive shortly after. A mismatch happens when the client's first render produces different markup than what the server actually sent — common causes are using `Date.now()` or `Math.random()` directly in render output, checking `window` or `localStorage` during the initial render (which don't exist on the server, so the server output differs), or browser extensions injecting attributes into the HTML before React hydrates it. ```jsx // Bug: server renders one timestamp, client renders a different one // moments later, so React sees mismatched text content on hydration. function Timestamp() { return {new Date().toLocaleTimeString()}; } ``` The fix is to make the very first client render deterministic and identical to the server's output, deferring anything client-only (like the real-time clock, or reading localStorage) to a useEffect that runs after hydration completes, so the visible content updates a moment later rather than mismatching immediately. suppressHydrationWarning exists for the rare, genuinely-expected case (like a relative timestamp that's supposed to differ slightly) but shouldn't be used to paper over a real bug.

Question 36

What is automatic batching in React 18, and how does it differ from React 17's batching behavior?

Accepted Answer

Batching means React groups multiple state updates together and re-renders only once for all of them, instead of re-rendering after each individual setState call. Before React 18, this only happened inside React's own event handlers (onClick, onChange) — if you called setState inside a native promise .then(), a setTimeout callback, or a raw addEventListener handler, React 17 would trigger a separate re-render for each call.

React 18's automatic batching extends this to ALL updates regardless of where they originate, so multiple setState calls inside a promise callback, timeout, or native event handler now also collapse into a single re-render, just like inside a React event handler.

```jsx
// React 17: two re-renders (once per setState, since this is inside a native promise callback)
// React 18: one re-render, automatically batched
fetch('/api/data').then(() => {
  setLoading(false);
  setData(result);
});
```

If you genuinely need a state update applied synchronously and immediately reflected in the DOM before the next line of code runs — rare, but sometimes needed for things like measuring layout right after an update — `flushSync(() => setState(...))` opts that specific update out of batching.

Question 37

What is the difference between React Server Components and Client Components?

Accepted Answer

Server Components render only on the server (or at build time) and never ship any of their own JavaScript to the browser — the browser only receives the HTML/serialized output they produced. This lets them do things a browser component can't, like directly querying a database or reading a secret API key with plain async/await in the component body, but they cannot use hooks like useState/useEffect, cannot attach event handlers, and cannot touch browser-only APIs, because none of that has meaning without a live JavaScript runtime in the browser. Client Components, marked with `'use client'` at the top of the file, are the familiar interactive React components — hydrated and running in the browser, free to use state, effects, and event handlers. ```jsx // UserProfile.jsx (Server Component by default) async function UserProfile({ id }) { const user = await db.users.findById(id); // direct DB access, fine on the server return ; } // LikeButton.jsx 'use client' function LikeButton() { const [liked, setLiked] = useState(false); // needs client interactivity return ; } ``` The composition rule flows one direction: Server Components can render Client Components as children, but a Client Component file cannot directly import a Server Component — it can only receive one as a `children`/prop passed down from a parent Server Component, since importing it client-side would defeat the purpose of it never shipping JS.

Question 38

What is React Fiber, and how did it change React's rendering model compared to the pre-Fiber stack reconciler?

Accepted Answer

Before React 16, reconciliation was implemented as a synchronous, recursive walk of the entire component tree using the JavaScript call stack directly — once React started rendering an update, it couldn't pause partway through. For a large tree, this meant a single big update could block the main thread long enough to visibly drop frames or delay responding to user input like typing or clicking.

Fiber reimplemented reconciliation from scratch as an incremental, unit-of-work data structure: each fiber node represents one component's pending work, linked into a tree React can walk piece by piece, yielding control back to the browser between units of work whenever something more urgent (like a keystroke) needs to run. Rendering became something React's scheduler could pause, abandon, or resume, rather than an all-or-nothing synchronous operation tied to the call stack.

This re-architecture didn't itself add new user-facing features, but it's the foundational engine that later concurrent features (Suspense, useTransition, time-slicing, priority-based scheduling) were built on top of — those features are only possible because the underlying rendering engine could already be interrupted and resumed, which the old stack reconciler had no mechanism for at all.

Question 39

What are 'Lanes' in React's internal scheduler, and how do they let React handle updates of different priority concurrently?

Accepted Answer

Lanes are React's internal representation of update priority as a bitmask, where each bit position is a distinct 'lane' an update can be assigned to (e.g. a dedicated lane for synchronous updates, separate lanes for different transition priorities, a lane for retry/Suspense work). This replaced React's earlier model based on numeric 'expiration times,' which was less flexible for representing overlapping or independently-schedulable work.

Because lanes are bits, React can combine multiple lanes that share the same priority into one batched render pass, while keeping lanes of genuinely different priority separately schedulable. This is what lets a low-priority transition (marked via startTransition, occupying a transition lane) be interrupted mid-render by an urgent update landing in the synchronous lane — say, a keystroke arriving while a large list is still being filtered in the background.

Concretely, this is the mechanism underneath the useTransition/useDeferredValue behavior described elsewhere: React doesn't process work strictly in the order it was requested; it renders whichever lane currently has the highest priority, can abandon a lower-priority lane's in-progress work to serve a newer high-priority one, and later resumes or restarts the interrupted lane's render once nothing more urgent remains. Ordinary application code never touches lanes directly — they're an internal implementation detail — but they explain why concurrent features behave the way they do rather than simply processing a FIFO queue of updates.

Question 40

What does React's 'use' hook do, and how is it allowed to be called conditionally when other hooks aren't?

Accepted Answer

use(resource) reads the value of a promise or a Context, and, unlike other hooks, it is explicitly permitted to be called inside conditionals, loops, or after early returns. When called with a promise that hasn't resolved yet, it suspends the component — throwing to the nearest Suspense boundary — until that promise settles, then returns the resolved value on the next attempt.

The reason it can break the normal Rules of Hooks is that React doesn't need to preserve call-order-indexed state for `use()` the way it does for useState/useContext — those hooks rely on a fixed position in a per-render linked list to know which stored state belongs to which call, whereas `use()` re-reads its resource fresh each time it's invoked rather than persisting anything across renders keyed by call order.

```jsx
function Comments({ commentsPromise }) {
  if (!commentsPromise) return null; // conditional before the hook call—fine for `use`
  const comments = use(commentsPromise); // suspends until resolved
  return comments.map(c => <Comment key={c.id} {...c} />);
}
```

This makes `use()` the primary tool for consuming promises passed down from Server Components, and for reading Context conditionally inside Client Components, in situations where a regular useContext call at the top level would be awkward or impossible.

Question 41

What is the React Compiler, and what problem does it solve that manual useMemo/useCallback usage doesn't reliably solve?

Accepted Answer

The React Compiler (previously known by the project name 'React Forget') is a build-time tool that statically analyzes your component code and automatically inserts memoization equivalent to useMemo, useCallback, and React.memo — based on tracking data flow and dependencies itself, rather than requiring the developer to hand-write dependency arrays.

Manual memoization has two common failure modes: forgetting to memoize something that's expensive or passed to a memoized child (causing unnecessary re-renders), or memoizing with an incorrect or incomplete dependency array (causing stale closures, a subtly different but equally real class of bug). Both are easy mistakes because dependency arrays are maintained by hand and don't get automatically checked against how the code actually evolves over time.

By inserting equivalent memoization automatically based on real static analysis of what a value actually depends on, the compiler removes the most common source of both under-memoization (performance) and over/incorrect-memoization (correctness) bugs, without the developer needing to reason about dependency arrays at all for the cases it covers. It doesn't eliminate every memoization need — it can't reason about external mutable state the compiler has no visibility into — but it targets the overwhelming majority of everyday useMemo/useCallback usage.

Question 42

What does the cache() function do in React Server Components, and how is it different from a plain module-level cache?

Accepted Answer

cache(fn) memoizes the result of a function call for the duration of a single request/render pass, keyed by the arguments it was called with. If multiple Server Components anywhere in the same render tree call the same cached data-fetching function with the same arguments — say, both a page header and a sidebar independently calling getUser(userId) — the actual underlying work (a database query, an API call) executes only once, and every caller receives the same deduplicated result.

```jsx
import { cache } from 'react';

const getUser = cache(async (id) => {
  return db.users.findById(id); // runs once per request, no matter how many components call getUser(id)
});
```

The key difference from a naive module-level cache (a plain object or Map declared outside any function) is scope and lifetime: a module-level cache persists across every request handled by that server process, which in a multi-user server would leak one user's cached data into another user's request unless you manually key and invalidate it. cache() is scoped to a single render/request automatically — it resets between requests — so it gives you request-level deduplication without any risk of cross-request data leakage or manual cache invalidation logic.

Question 43

What is the difference between renderToString and renderToPipeableStream (or renderToReadableStream) for server-side rendering?

Accepted Answer

renderToString synchronously builds the ENTIRE HTML output into one big string in memory before sending anything to the client. This means Time To First Byte is gated on the slowest part of the whole page — if one section is waiting on a slow data fetch inside a Suspense boundary, the entire response waits for it, even though other parts of the page were ready much earlier. It also blocks Node's event loop while constructing a large string for a big page.

renderToPipeableStream (Node streams) and renderToReadableStream (Web Streams API, used in edge runtimes) instead render and flush HTML incrementally: the initial 'shell' of the page streams out as soon as it's ready, and any Suspense boundaries still waiting on data are sent later as additional chunks, each accompanied by a small inline script that patches the already-sent HTML in place once that boundary's data resolves.

```jsx
renderToPipeableStream(<App />, {
  onShellReady() {
    response.setHeader('content-type', 'text/html');
    pipe(response); // start streaming immediately, slow parts fill in later
  },
});
```

The practical benefit is that users see and can start interacting with the fast parts of the page immediately, instead of the whole page being held hostage by whichever single section happens to be slowest that request.

Question 44

Why does calling startTransition matter for whether a state update is treated as low priority, and what happens if you call setState after an await inside the transition callback?

Accepted Answer

startTransition marks whatever state update happens SYNCHRONOUSLY inside its callback as a low-priority 'transition' — React tags that specific update so it can be interrupted by higher-priority work (like a keystroke) and re-attempted later. The marking only applies to the synchronous portion of the callback that actually calls the setter.

If the callback is async and you call setState AFTER an `await`, that continuation resumes as a separate microtask outside of the synchronous scope startTransition was tracking — React has no way to retroactively tag it as part of the original transition, so by default it's treated as a normal, urgent update rather than a deprioritized one.

```jsx
startTransition(async () => {
  const results = await search(query); // this resumes as a plain microtask
  setResults(results); // NOT automatically treated as part of the transition
});
```

React 19's Actions (async functions passed to form action props, combined with useActionState/useOptimistic) handle this specific case correctly for form submissions by design — but for a hand-rolled startTransition callback, the safe rule is that the setState call needs to happen synchronously inside the callback for the low-priority tagging to actually apply; async logic that eventually calls setState after awaiting something doesn't inherit that tag automatically.

Question 45

What is the getServerSnapshot argument in useSyncExternalStore for, and why does it matter for server-rendered apps?

Accepted Answer

useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot) needs a distinct server-side snapshot function because, during server rendering, there's no real browser environment or live external store subscription to read from — something like `window.innerWidth` or a WebSocket connection simply doesn't exist on the server, so calling the normal getSnapshot there would either throw or return a meaningless value.

getServerSnapshot supplies a fixed, deterministic value React can safely use to produce the initial server-rendered HTML, which also has to exactly match what the client renders on its first pass so hydration doesn't immediately mismatch.

```jsx
function useWindowWidth() {
  return useSyncExternalStore(
    (cb) => { window.addEventListener('resize', cb); return () => window.removeEventListener('resize', cb); },
    () => window.innerWidth,
    () => 1024 // fixed default used only during SSR
  );
}
```

Omitting getServerSnapshot for a store that's only meaningful client-side causes the hook to throw during server rendering, since React has no safe fallback value to render. Supplying a sensible default lets the component render successfully on the server (typically showing a reasonable default layout), and then the real client value takes over immediately after hydration completes.

Question 46

What problem does React's experimental Activity (formerly Offscreen) concept solve for hidden or backgrounded UI?

Accepted Answer

Historically, apps had a binary choice for content that's temporarily not visible — a background tab in a tabbed interface, a screen navigated away from but likely to be revisited: either unmount it, which discards all component state, scroll position, in-progress form input, or DOM state (like video playback position); or keep it mounted and rendered normally, which means paying the full ongoing cost of its effects and re-renders even though nothing about it is visible to the user right now.

Activity introduces a third option native to React: a part of the tree can be marked hidden while staying mounted, preserving its component state, DOM nodes, and internal instance data, but its effects are deprioritized or paused while it's not visible, so it doesn't consume rendering/effect resources for content nobody can currently see.

A concrete case is a tabbed dashboard where switching tabs today either loses whatever the user was scrolled to or typed into the previous tab (unmount approach), or keeps every tab's timers, subscriptions, and re-renders running simultaneously in the background even though only one tab is visible (always-mounted approach). Activity is meant to give React a native way to say 'keep this alive, but don't spend resources on it right now,' rather than forcing that all-or-nothing tradeoff onto every app that needs it.

Question 47

Why can a value wrapped in useMemo still cause a component to re-render, and what's the common mistake that defeats useMemo entirely?

Accepted Answer

useMemo only controls whether the computation inside it re-runs — it has no effect on whether the component itself re-renders when its parent re-renders, and it has no effect on whether a child receiving the memoized value re-renders, unless that child is also wrapped in React.memo. People sometimes expect useMemo alone to prevent downstream re-renders, but it's only skipping recomputation, not skipping rendering.

A separate, very common mistake is passing a dependency to useMemo that is itself freshly created every render — an inline array or object literal in the dependency list.

```jsx
// Bug: options is a new array reference every render, so useMemo's
// dependency 'changed' every time, and it recomputes every render anyway
const filtered = useMemo(() => filterItems(items, ['a', 'b']), [items, ['a', 'b']]);

// Fix: define the stable array outside, or memoize it too
const STATIC_OPTIONS = ['a', 'b'];
const filtered = useMemo(() => filterItems(items, STATIC_OPTIONS), [items]);
```

Both of these are 'useMemo isn't doing what I think it's doing' bugs — the first is a misunderstanding of scope (it memoizes a value, not a render), the second is an actual bug where the memoization silently never fires because a dependency's reference changes every time regardless of whether its content did.

Question 48

Why does changing an element's key prop force React to unmount and remount it, rather than update it in place?

Accepted Answer

React identifies an element during reconciliation using the combination of its component type and its key. If the type is the same but the key changes between renders, React treats it as a semantically different element occupying that position — not the same instance with different props — so it unmounts the old instance entirely (running its effect cleanups, discarding its internal state and refs) and mounts a fresh new instance, rather than diffing and updating the existing one in place.

This is a deliberate, useful behavior rather than just a quirk to work around: changing key on purpose is a common pattern for forcing a full reset of a component's internal state without writing manual reset logic.

```jsx
// Switching which record is being edited resets ALL of the form's
// internal state (draft text, validation errors, touched fields) for free,
// because React treats each userId as mounting a brand new EditForm.
<EditForm key={selectedUserId} userId={selectedUserId} />
```

Without the key change, EditForm would just receive a new userId prop and keep its existing internal state (e.g. a partially-typed draft for the previous user) unless you wrote explicit useEffect logic to detect the id change and manually reset every piece of state yourself.

Question 49

Why shouldn't you call hooks inside a loop, even if that loop always runs the exact same number of times every render?

Accepted Answer

React's guarantee about hooks depends entirely on call order being IDENTICAL across every render of a component, and it relies on this being structurally impossible to violate, not just true by coincidence given the current code. A loop that 'always' runs a fixed number of iterations today is only safe as long as nobody ever changes that — add one more conditional branch, change what the loop iterates over, or introduce an early return, and the iteration count can silently start varying without necessarily looking like an obviously risky change to whoever makes it.

```jsx
// "Safe" today because fields.length happens to always be 3,
// but nothing prevents fields from changing length later
fields.forEach((field) => {
  const [value, setValue] = useState(field.default); // hooks inside a loop
});
```

Because React's linked-list-based hook tracking has no way to verify at runtime that a loop's iteration count is guaranteed constant, the eslint-plugin-react-hooks rule flags any hook call that isn't structurally at the top level, regardless of whether the current code happens to be safe — the whole point of the rule is protecting against future edits breaking an invariant that isn't otherwise enforced anywhere.

Question 50

How does StrictMode's double-invocation of reducer and state-initializer functions differ in purpose from its double-invocation of effects?

Accepted Answer

StrictMode double-invokes render-phase functions — the component's own render, plus useState/useReducer's lazy initializer functions and the reducer function itself — purely as a diagnostic check for impurity. These functions are supposed to be pure (no side effects, no mutating anything outside their own scope), so calling them twice and discarding the second call's result is meant to surface bugs like a reducer that pushes into a module-level array or calls an API directly, since a truly pure function wouldn't behave any differently when called twice with the same input. Only the first call's result is actually committed to state — the second is purely for detection and never affects the app.

Effect double-invocation is a fundamentally different kind of check: React actually runs the full mount → cleanup → mount-again cycle for real, simulating what would happen if the component were unmounted and remounted (as could genuinely occur with fast refresh during development, or with future features that keep hidden trees mounted and reactivate them). This is meant to catch a missing or incorrect cleanup function — if an effect subscribes to something in its setup but doesn't properly unsubscribe in its cleanup, the deliberate extra mount/cleanup cycle makes a resulting bug (like a duplicated event listener or double-fired subscription) visible immediately in development, rather than only showing up in production under a specific fast-refresh or remount scenario.

The distinction matters practically: a component failing the render/reducer purity check has a bug in code that should never have side effects at all, whereas a component failing the effect check has a bug specifically in its cleanup logic not properly undoing its own setup.

Question 51

What is JSX, and how does it actually turn into code a browser can run?

Accepted Answer

JSX (JavaScript XML) is the HTML-like syntax you write inside your React components, e.g. `

Hello

` sitting right in the middle of a JavaScript file. Browsers have no idea what to do with that on their own — a build tool (Babel under the hood, whether you're using Vite, Create React App, or Next.js) compiles every JSX tag into a plain JavaScript function call before your code ever reaches the browser. Concretely, `

Hello, {name}!

` gets compiled into something like `React.createElement('h1', { className: 'title' }, 'Hello, ', name, '!')`. That function call just returns a plain JavaScript object describing what should appear on screen (tag name, props, children) — React then uses that object to figure out what to actually draw. So JSX isn't a separate language feature React 'runs'; it's pure syntax sugar that disappears at build time. ```jsx function Greeting({ name }) { return (

Hello, {name}!

{name === 'Admin' && (admin)}

); } ``` A few things fall out of JSX being 'just JavaScript in disguise': you use `className` instead of `class` (since `class` is a reserved JS keyword), attribute names are camelCase (`onClick`, not `onclick`), you can drop any JavaScript expression inside curly braces `{}` (a variable, a ternary, a function call), and a component can only return one root element — which is exactly why `<>...` (Fragment) exists, to group multiple elements without adding an extra wrapper `

` to the real DOM.

Question 52

What is the difference between a functional component and a class component in React?

Accepted Answer

Both are just two different ways to write the same thing: a component that takes props and returns UI. A class component extends `React.Component` and defines its output in a `render()` method, reading props via `this.props` and managing state via `this.state` plus `this.setState()`. A functional component is simply a JavaScript function that takes props as an argument and returns JSX directly — no `this`, no class boilerplate. Before 2019, class components were the only way to have local state or hook into lifecycle events (mounting, updating, unmounting) — plain functions could only render static, stateless output. Hooks (`useState`, `useEffect`, etc.) changed that: they let a plain function component hold its own state and run side effects, which is why functional components are now the standard way to write React, and most new codebases and tutorials use them almost exclusively. ```jsx // Class component class Counter extends React.Component { state = { count: 0 }; render() { return ( ); } } // The same component, written as a function with hooks function Counter() { const [count, setCount] = useState(0); return ; } ``` The functional version is shorter, avoids the classic `this`-binding gotchas (forgetting to bind an event handler in the constructor was a very common class-component bug), and lets you reuse stateful logic across components via custom hooks — something class components could only do clumsily, through patterns like higher-order components or render props. Class components still work and you'll see them in older codebases, but for new code, functional components with hooks are what you should reach for.

React Interview Questions & Answers

Ready to practice these live?