Q: What are hooks, and what are the Rules of Hooks?

Hooks are functions whose names start with use that let function components use React features: state (useState), effects (useEffect), context (useContext), refs and more. They were introduced in React 16.8. The rules: - Only call hooks at the top level of a component or custom hook: never inside conditions, loops, nested functions, or after an early return. - Only call hooks from React functions: components and custom hooks, not plain utility functions or event handlers. The reason is that React doesn't identify hooks by name; it relies on call order. On every render it walks through the hook calls in sequence and matches each one to its stored state. If a condition skips one call, every later hook reads the wrong slot. eslint-plugin-react-hooks catches violations. The exception is React 19's use API, which can be called conditionally.

Question 1

What is React, and what does it mean that React is declarative?

Accepted Answer

React is a JavaScript library for building user interfaces out of reusable components. It focuses on the view layer; routing, data fetching and build tooling come from the ecosystem or from a framework like Next.js or React Router.

Declarative means you describe what the UI should look like for the current state, and React works out how to update the DOM to match. You don't call appendChild or classList.add by hand; you write {isOpen && <Menu />} and change isOpen. The mental model is roughly UI = f(state).

This makes components predictable, because their output depends only on props and state, and lets you build complex screens by composing small pieces. React also batches and minimizes the DOM work for you. It isn't tied to the browser either: react-dom renders to the DOM, while React Native renders to native mobile views.

Question 2

What is the virtual DOM, and how does React use it to update the page?

Accepted Answer

The virtual DOM is React's in-memory description of the UI: a tree of plain JavaScript objects called React elements, produced when your components render. <button className="primary">Save</button> becomes an object roughly like { type: 'button', props: { className: 'primary', children: 'Save' } }.

When state changes, React re-renders the affected components to get a new tree, compares it with the previous one (reconciliation), and then applies only the necessary changes to the real DOM in the commit phase.

The point isn't that the virtual DOM is faster than the DOM: a hand-written, targeted DOM update is always faster. The benefit is that you write simple declarative code that conceptually re-renders everything, while React keeps the actual DOM work small and batched. Internally, React tracks this work in a structure called the Fiber tree.

Question 3

What is JSX, and what does it compile to?

Accepted Answer

JSX is a syntax extension that lets you write markup-like code inside JavaScript. Browsers can't run it, so a compiler such as Babel, SWC, esbuild or TypeScript turns it into plain function calls. With the modern automatic runtime, a JSX element compiles to a jsx(type, props) call imported from react/jsx-runtime. The older classic transform produced React.createElement(...), which is why old files had to import React.

Rules worth knowing:

It's JavaScript, so attributes are camelCase (className, htmlFor, onClick), and {} embeds any expression, but not statements like if or for.
A component returns a single root, so siblings go inside a Fragment.
Capitalized tags like <Card /> are components; lowercase tags are DOM elements.
Strings embedded with {} are escaped, which protects against XSS.

Question 4

What is a component in React, and how do props work?

Accepted Answer

A component is a reusable, self-contained piece of UI. In modern React it's a JavaScript function that receives a single props object and returns JSX. Its name must start with a capital letter, so JSX treats it as a component rather than an HTML tag.

Props are how a parent passes data and behavior down to a child: strings, numbers, objects, callbacks like onSelect, even other JSX. The special children prop holds whatever you nest between the opening and closing tags, which enables composition such as <Card><Avatar /></Card>.

Props are read-only. A component must never modify its own props; if a value needs to change over time, it belongs in state, either in this component or in a parent that passes a new value down. Default values are usually written as destructuring defaults, for example function Button({ size = 'md' }).

Question 5

What is the difference between props and state?

Accepted Answer

Props are inputs a component receives from its parent. The component can't change them; it re-renders with new props when the parent re-renders and passes different values. State is data a component owns and manages itself, created with useState or useReducer. Updating it through the setter schedules a re-render of that component and its children. A useful way to decide: - If a value comes from the parent, it's a prop. - If it changes over time because of user interaction or async results, and this component owns it, it's state. - If it can be calculated from other props or state, it's neither: compute it during render. The two connect: a parent's state is often passed to a child as props, together with a callback so the child can ask the parent to update it. That's React's one-way data flow.

Question 6

How does useState work, and why does logging the state right after calling its setter show the old value?

Accepted Answer

useState(initial) returns a pair: the current value and a setter. React stores the value outside your function, attached to this component's position in the tree, so it survives between renders. Calling the setter doesn't change the variable you already have. It queues an update and schedules a re-render; on the next render, useState returns the new value. So after setCount(count + 1), logging count still shows the old value. Each render sees its own snapshot of state, and a const from that render never changes. Other details: - If the new value is the same as the current one by Object.is, React skips the re-render. - For expensive initial values pass a function, useState(() => parse(data)), so it runs only on the first render. - When the next value depends on the previous one, pass an updater: setCount(c => c + 1).

Question 7

Explain useEffect. When does it run, and how does the dependency array change that?

Accepted Answer

useEffect(setup, deps?) lets a component synchronize with something outside React: a subscription, a timer, a network request, a non-React widget. React runs the setup after the render is committed, usually after the browser has painted, so it doesn't block the screen update. The dependency array controls when it runs again: - No array: after every render. - []: only after the first render (mount). - [a, b]: after mount, and after any render where a or b changed, compared with Object.is. If setup returns a function, that's the cleanup. React calls it before re-running the effect with new dependencies, and when the component unmounts. Every reactive value the effect reads (props, state, functions declared in the component) should be listed; the react-hooks/exhaustive-deps lint rule enforces this. Think "what does this effect stay in sync with", not "which lifecycle moment is this".

Question 8

Why do list items need a key, and what can go wrong if you use the array index as the key?

Accepted Answer

When rendering a list, React uses key to match each child with its counterpart from the previous render. Keys tell React which item is which, so when the list changes it can move, insert or remove the right DOM nodes and keep each item's state attached to the correct item. With the index as key, identity is tied to position, not to the data. If you insert at the top, delete from the middle, sort or filter, items shift to different indexes. React then reuses the wrong component instances: an uncontrolled input keeps text typed into another row, a checkbox stays checked on the wrong item, and more rows re-render than necessary. Good keys are stable and unique among siblings, typically an id from the data. The index is acceptable only for static lists that never reorder or change. Never generate keys during render with Math.random(): every render would remount every item. Keys aren't passed to the component as a prop.

Question 9

What are the differences between class components and function components, and why did React move to function components?

Accepted Answer

Class components extend React.Component, keep state in this.state, update it with this.setState, and put side effects in lifecycle methods like componentDidMount, componentDidUpdate and componentWillUnmount. Function components are plain functions that return JSX and use hooks for state and effects. Why function components with hooks won: - Reusable logic: custom hooks replaced higher-order components and render props, which caused deeply nested "wrapper hell". - Related code stays together: one effect holds a subscription and its cleanup, instead of splitting it across three lifecycle methods. - No this: no binding event handlers, and no surprises from reading this.props in async callbacks after it changed. - Less boilerplate, and better support from tools such as the React Compiler. Classes are still supported, and you still need one for an error boundary, because there's no hook equivalent of componentDidCatch. New code should use function components.

Question 10

What are hooks, and what are the Rules of Hooks?

Accepted Answer

Hooks are functions whose names start with use that let function components use React features: state (useState), effects (useEffect), context (useContext), refs and more. They were introduced in React 16.8.

The rules:

Only call hooks at the top level of a component or custom hook: never inside conditions, loops, nested functions, or after an early return.
Only call hooks from React functions: components and custom hooks, not plain utility functions or event handlers.

The reason is that React doesn't identify hooks by name; it relies on call order. On every render it walks through the hook calls in sequence and matches each one to its stored state. If a condition skips one call, every later hook reads the wrong slot. eslint-plugin-react-hooks catches violations. The exception is React 19's use API, which can be called conditionally.

Question 11

What does "lifting state up" mean, and when do you do it?

Accepted Answer

When two components need to share the same data or stay in sync, you move that state to their closest common parent. The parent owns the state and passes it down as props, together with callbacks the children call to request changes.

Classic example: an accordion where only one panel can be open at a time. If each Panel has its own isOpen state, they can't coordinate. Lift it into Accordion as activeIndex, then pass each panel isActive and an onShow callback.

This keeps a single source of truth: each piece of state lives in exactly one component, and everything else derives from it. The trade-off is that the parent now re-renders on every change, and props may have to travel through several levels. Lift state only as high as it needs to go; if you're lifting very high just to reach distant components, consider composition, context or a store.

Question 12

What is one-way data flow in React, and how does a child component send data back to its parent?

Accepted Answer

In React, data flows down the tree: parents pass values to children through props, and children can't modify those props. When state changes, the new values flow down on the next render. This makes it easy to trace where a value comes from: follow the props up to the component that owns the state. A child communicates upward by calling a callback that the parent passed as a prop, such as onChange(newValue) or onDelete(id). The child only reports what happened; the parent owns the state and decides how to update it. Compared with two-way binding, like [(ngModel)] in Angular, this is more explicit: a controlled input needs both value and onChange. The payoff is predictability. There's exactly one place that can change a given piece of state, which makes updates easier to reason about and debug.

Question 13

What exactly is the difference between useMemo and useCallback, and how could you write one using the other?

Accepted Answer

Both cache something between renders and recompute only when a dependency changes (compared with Object.is). The difference is what they cache:

useMemo(() => compute(a, b), [a, b]) calls your function and caches its return value.
useCallback(fn, [a, b]) caches the function itself, without calling it.

So useCallback(fn, deps) is equivalent to useMemo(() => fn, deps).

Use useMemo to skip an expensive calculation, like filtering a large list, or to keep an object or array referentially stable. Use useCallback when a function is passed to a memo-wrapped child or used as a dependency of an effect or another hook. Without a consumer that cares about identity, useCallback achieves nothing: the inline function is still created on every render, React just hands back the cached one. Both are performance hints, so your code must still behave correctly without them.

Question 14

You wrapped a child in React.memo, but it still re-renders every time the parent does. What are the likely causes?

Accepted Answer

memo skips a re-render only when every prop is equal to its previous value by Object.is, which is a shallow reference comparison. The usual culprit is a prop recreated on every parent render: - inline objects or arrays: style={{ color: 'red' }}, options={[1, 2]}, - inline functions: onClick={() => select(id)}, - JSX passed as children, since each render creates new element objects. Each render makes a new reference and {} !== {}, so the comparison fails. Fixes: hoist constants outside the component, wrap objects in useMemo and callbacks in useCallback, or pass primitives instead of objects. Also check what memo can't block: the child still re-renders when its own state changes or when a context it reads changes. You can pass a custom comparison function as the second argument, but it must compare every prop, including functions, or you'll get stale closures. The React Compiler can handle most of this automatically.

Question 15

What is the difference between useRef and useState? When would you keep a value in a ref instead of state?

Accepted Answer

Both persist a value across renders, but they behave differently when the value changes:

useState gives you a value and a setter; updating it triggers a re-render, and the new value appears in the next render's snapshot.
useRef gives you a mutable object, { current }, that stays the same object for the component's lifetime. Assigning ref.current = x takes effect immediately and does not re-render.

Use state for anything that affects what's on screen. Use a ref for values that event handlers or effects need but rendering doesn't: an interval or timeout id, an AbortController, the previous value of a prop, a flag like "already sent analytics", or a DOM node via ref={inputRef}.

Avoid reading or writing ref.current during render (lazy initialization aside). React doesn't know when a ref changes, so UI that depends on it can silently get out of sync.

Question 16

What is state batching, and why would you use a functional update like setCount(c => c + 1)?

Accepted Answer

Batching means React groups several state updates made in the same event into a single re-render. Since React 18 with createRoot, this automatic batching also applies inside promises, setTimeout and native event handlers, not only in React event handlers. It avoids wasted renders and half-updated UI. Batching interacts with snapshots. Inside one handler, count is fixed for that render, so calling setCount(count + 1) three times queues "set to 1" three times, and the result is 1. An updater function is queued instead of a value; React applies the queue in order, passing each updater the result of the previous one, so three setCount(c => c + 1) calls produce 3. Use the updater form whenever the next state depends on the previous one, especially in async callbacks, intervals or effects where the captured value may be stale. If you really need an update applied synchronously, for example before measuring the DOM, flushSync from react-dom exists, but it's rarely needed.

Question 17

What is prop drilling, and what are the ways to avoid it?

Accepted Answer

Prop drilling is passing props through several layers of components that don't use them, only so that a deeply nested component can receive them. It makes the intermediate components noisy, couples them to data they don't care about, and makes refactoring painful.

Ways to avoid it, roughly in the order I'd try them:

Composition: pass JSX through children or other props, so the component that owns the data renders the deep component directly, e.g. <Layout sidebar={<UserMenu user={user} />} />. This often removes the drilling entirely.
Context: for data many components need at different depths, like the theme, locale or current user.
A store like Zustand, Redux Toolkit or Jotai for frequently updated global client state, and TanStack Query or similar for server data, which any component can read directly.

Passing a prop through two or three levels is fine and explicit; it's only a problem when it becomes deep and widespread.

Question 18

How do you create and consume a Context with useContext? What happens if there is no matching provider?

Accepted Answer

Three steps: - Create it: const ThemeContext = createContext('light'). The argument is the default value. - Provide a value above the consumers. In React 19 you can render the context itself as the provider, ; older versions use . - Read it with useContext(ThemeContext) in any descendant. useContext returns the value of the closest provider above the calling component, so nested providers can override the value for a subtree. If there's no provider above, it returns the default passed to createContext, which never changes. A common pattern is a null default plus a custom hook that throws a helpful error when the provider is missing. When the provider's value changes, every consumer re-renders, so avoid passing a fresh object on every render. React 19 can also read context with use(ThemeContext), which, unlike useContext, may be called inside conditions.

Question 19

Is React Context a state management solution? How does it compare with Redux or Zustand?

Accepted Answer

Strictly speaking, Context is a dependency injection mechanism: it passes a value down the tree without props. It doesn't manage anything itself; the state still lives in useState or useReducer in the provider component. Context plus useReducer gives you a small store, but with limits: - Every consumer re-renders when the value changes. There are no selectors, so a component can't subscribe to just one slice. - There's no built-in middleware, devtools or persistence. Redux Toolkit provides a single store with actions, reducers, selectors, middleware and excellent devtools, including time-travel debugging. It suits large apps and teams that want strict conventions. Zustand is a minimal hook-based store with selector subscriptions and very little boilerplate. With both, a component re-renders only when the data it selects changes. My rule of thumb: Context for low-frequency values like theme, locale or auth; a store for frequently updated, widely shared client state; and neither for server data, which belongs in TanStack Query or a framework's loaders.

Question 20

When would you use useReducer instead of useState?

Accepted Answer

useReducer(reducer, initialState) returns [state, dispatch]. Instead of setting state directly, event handlers dispatch actions that describe what happened, like { type: 'added', text }, and a pure reducer(state, action) function computes the next state. I reach for it when: - several pieces of state change together, e.g. status, data and error for a request, - the next state depends on the previous one in non-trivial ways, - many event handlers update the same state and I want the update logic in one place, - I want to unit test the logic in isolation, since a reducer is a plain function. dispatch also has a stable identity, so it can go through context or to memoized children without useCallback. For simple independent values, like a toggle or a single input, useState is shorter and clearer. The reducer must be pure and return new objects instead of mutating; in development, StrictMode calls it twice to surface impurity.

Question 21

How would you build a form with several inputs in React and handle its submission?

Accepted Answer

The most common pattern is controlled inputs: keep the values in state, set each input's value from state, and update it in onChange. With several fields, one state object plus a single change handler keyed by the input's name keeps it short. For submission, handle onSubmit on the <form> element rather than a button's click, so pressing Enter works too. Call e.preventDefault() to stop the browser's full-page submission, then validate and send the data. Details worth mentioning: - Checkboxes use checked instead of value, and you read e.target.checked. - Give every input a label, linked with htmlFor and id, for accessibility. - Controlled inputs re-render on every keystroke, so for large forms libraries like React Hook Form use uncontrolled inputs, often with a schema validator like Zod. In React 19 you can also pass a function to the form's action prop; it receives the FormData and React tracks the pending state for you.

Question 22

Why should you never mutate state directly, and how do you correctly update an object or array held in state?

Accepted Answer

React decides whether state changed by comparing the old and new values with Object.is. If you mutate an object and pass the same reference back, as in user.name = 'Ada'; setUser(user), React sees no change and can skip the re-render. Even when something else triggers a render, mutation breaks everything that relies on comparing references, such as memo, useMemo and effect dependencies, and it corrupts the previous render's snapshot.

Treat state as immutable and create new values instead:

Objects: setUser({ ...user, name: 'Ada' }). Spread is shallow, so copy each nested level you change.
Arrays: add with [...items, item], remove with filter, update with map returning a new object for the changed item.
Sorting or reversing: copy first, [...items].sort(), or use toSorted().

push, splice, sort, reverse and direct assignment all mutate in place. For deeply nested updates, Immer lets you write mutating-style code that produces immutable copies.

Question 23

How do class lifecycle methods like componentDidMount and componentWillUnmount map to hooks?

Accepted Answer

The rough mapping: - constructor and initial state: useState(initial) or a lazy initializer. - componentDidMount: useEffect(() => { ... }, []). - componentDidUpdate: useEffect with the relevant dependencies (which also runs after mount). - componentWillUnmount: the cleanup function returned from an effect. - shouldComponentUpdate or PureComponent: memo. - getDerivedStateFromProps: usually compute the value during render, or reset with a key. - componentDidCatch and getDerivedStateFromError: no hook equivalent; you still need a class error boundary. But I'd stress that effects aren't lifecycle methods. An effect describes how to start and stop synchronizing with something, based on its dependencies. Instead of spreading one subscription across mount, update and unmount methods, a single effect sets it up, cleans it up, and re-runs when the values it uses change. Thinking in lifecycles is how people end up with missing dependencies and stale data.

Question 24

When a parent component re-renders, do its children re-render too? How can you avoid unnecessary child renders?

Accepted Answer

Yes. By default, when a component renders, React re-renders every component it renders, recursively, whether or not their props changed. React doesn't compare props unless you opt in. Usually that's fine: renders are cheap, and React only touches the DOM where the output actually differs.

When a child is expensive, the options are:

Move state down: if only a small part of the UI uses some state, put that state in a smaller component so fewer components re-render.
Lift content up as children: when a component re-renders because of its own state, the children elements it received from its parent are the same objects as before, so React skips re-rendering them.
memo the expensive child and keep its props referentially stable with useMemo and useCallback.
Split contexts, so an update only reaches the components that need it.

Measure first with the React DevTools Profiler. With the React Compiler enabled, much of this memoization happens automatically.

Question 25

A React page feels slow. How would you find and fix the performance problem?

Accepted Answer

First measure, don't guess. The React DevTools Profiler shows which components render, how often and how long they take; the browser's Performance panel shows long tasks, layout thrashing and network waterfalls. Profile a production build, because development mode is much slower. Then fix what the profile shows: - Too many re-renders: move state closer to where it's used, pass content as children, split contexts, memo expensive children with stable props, or enable the React Compiler. - Expensive renders: useMemo heavy calculations and virtualize long lists. - Updates blocking input: mark non-urgent updates with startTransition or useDeferredValue so typing stays responsive. - Slow loading: code-split routes and heavy widgets with lazy, trim dependencies, optimize images, and remove request waterfalls by fetching in parallel or on the server. - Unneeded effects that set state and cause extra render passes. Afterwards, verify the improvement with the same measurement, and watch real-user metrics like INP and LCP.

Question 26

What are Fragments, and why would you use them?

Accepted Answer

A component has to return a single root, but wrapping siblings in an extra div adds meaningless nodes to the DOM. A Fragment groups children without creating any DOM element. You write it as <>...</> or <Fragment>...</Fragment>.

Why it matters:

Valid HTML: a component that returns several table cells, list items or dt/dd pairs can't wrap them in a div without producing invalid markup.
Layout: extra wrappers break CSS flexbox and grid layouts, where the styled items must be direct children of the container.
A cleaner, shallower DOM.

The short syntax can't take any attributes. When you render fragments in a list, use the explicit form so you can give each one a key: <Fragment key={item.id}>. The key is the only attribute you'd normally pass to a Fragment.

Question 27

What are the common ways to render something conditionally in React, and what is the gotcha with &&?

Accepted Answer

JSX is just JavaScript, so you use ordinary JavaScript:

if with an early return for whole-component branches: if (!user) return <Login />.
Ternary for either/or inline: {isLoading ? <Spinner /> : <Table />}.
Logical && to render something or nothing: {hasError && <Alert />}.
Return null to render nothing at all.
A variable or lookup object for many cases, instead of nested ternaries.

The && gotcha: a && b evaluates to a when a is falsy. React renders nothing for false, null and undefined, but it does render the number 0. So {items.length && <List />} shows a stray "0" when the list is empty. Make the left side a real boolean, items.length > 0 && ..., or use a ternary.

Also remember that switching between different component types at the same position unmounts one and mounts the other, so its state is lost.

Question 28

Why does React favor composition over inheritance? Give examples of composition in practice.

Accepted Answer

In React you build complex components by combining smaller ones rather than extending base component classes. The React team has long said they haven't found use cases where they'd recommend component inheritance hierarchies, and in practice you almost never see class FancyButton extends Button. Composition tools: - children: generic containers like Card, Modal or Layout don't know their content ahead of time; they render whatever is nested inside them. - Named slots: props that accept JSX, e.g. } sidebar={} />. - Specialization by wrapping: a DangerButton that renders

Question 29

Compare higher-order components, render props and custom hooks as ways to share logic between components.

Accepted Answer

All three solve "reuse stateful logic", and they arrived in roughly this order:

A higher-order component is a function that takes a component and returns a new one with extra props, like withAuth(Dashboard) or the old Redux connect. Downsides: extra wrapper layers, props whose origin is unclear, and name collisions when several HOCs are stacked.
Render props: a component receives a function and calls it with its data to decide what to render. More explicit, but nesting several produces a pyramid of callbacks.
Custom hooks: const user = useUser(). No extra components in the tree, explicit inputs and outputs, and easy to compose and test.

Today I default to custom hooks. HOCs still appear in libraries for cross-cutting wrappers, and render props or function-as-children remain useful when a component should let its caller control what gets rendered with its data, such as a virtualized list's row renderer.

Question 30

Walk me through writing a useDebouncedValue custom hook for a search input.

Accepted Answer

The hook keeps its own debounced state. Whenever value changes, the effect starts a timer that copies the value into that state after delay milliseconds. The key is the cleanup. If value changes again before the timer fires, React runs the previous effect's cleanup first, which clears the pending timer, so only the last value within the window gets through. The cleanup also clears the timer on unmount, so nothing updates after the component is gone. Design points I'd mention: - It's named use... and calls hooks at the top level, so it follows the Rules of Hooks. - Both value and delay are dependencies, so changing the delay works correctly. - Every component that calls it gets independent state. - The input stays controlled by the raw query, so typing is instant; only debouncedQuery drives the fetch or filter. Unlike useDeferredValue, this uses a fixed delay, which is what you want when the goal is fewer network requests rather than smoother rendering.

Question 31

What happens to a React app when a component throws an error during rendering, and how do you contain the damage?

Accepted Answer

If nothing catches it, React unmounts the entire root and the user sees a blank page. That's deliberate: leaving corrupted UI on screen, like a checkout showing the wrong total, is considered worse than removing it. To contain it you use error boundaries: components that catch errors thrown while rendering the tree below them and render a fallback instead. They're still class components: static getDerivedStateFromError switches to the fallback, and componentDidCatch logs the error. Many teams use the react-error-boundary package, which adds reset support. In React 19, createRoot also accepts onCaughtError and onUncaughtError options for centralized reporting. Place boundaries deliberately: one near the root as a last resort, one per route, and around independent widgets so a broken sidebar doesn't take down the whole page. Boundaries don't catch errors in event handlers or asynchronous code, so handle those with try/catch.

Question 32

What is code splitting, and how do you implement it in a React app?

Accepted Answer

Code splitting breaks the JavaScript bundle into smaller chunks that load on demand, so users download only the code for what they're looking at. It improves initial load and time to interactive.

The mechanism is dynamic import(), which bundlers like Vite and webpack turn into a separate chunk. In React you combine it with lazy and <Suspense>: const Settings = lazy(() => import('./Settings')) loads the chunk the first time Settings renders, while the nearest Suspense boundary shows a fallback.

Where to split:

Routes first: each page becomes its own chunk. Frameworks like Next.js do this automatically.
Heavy, rarely used components: rich-text editors, charts, maps, big modals.
Large libraries needed in one place, which you can import() inside an event handler.

Watch out for over-splitting, which adds request overhead, and for spinners on every click: you can preload a chunk, for example on hover, by calling the same import() early. Wrap lazy areas in an error boundary, since loading a chunk can fail.

Question 33

What are synthetic events in React, and how does React event handling differ from native DOM events?

Accepted Answer

React passes your handlers a SyntheticEvent: a cross-browser wrapper around the native event with the familiar interface, such as e.target, e.preventDefault() and e.stopPropagation(). The underlying event is available as e.nativeEvent. Differences from plain DOM handling: - Handlers are camelCase props that take functions, onClick={handleClick}, not strings. - You must call e.preventDefault(); returning false does nothing. - React uses event delegation: rather than a listener on every element, it listens at the root container (since React 17; before that, on document) and dispatches through the component tree. - Propagation follows the React tree, so an event inside a portal bubbles to the portal's React parent even though its DOM node lives elsewhere. - onChange fires on every keystroke, like the native input event, not only when the field loses focus. - Event pooling was removed in React 17, so reading e inside async code is safe. Capture-phase handlers use a Capture suffix, like onClickCapture.

Question 34

Why does this effect cause an infinite loop of requests, and how do you fix it?

Accepted Answer

params is a new object on every render, and effect dependencies are compared with Object.is. Two different objects are never equal, so the effect runs after every render. Each run fetches and calls setData with a new array, which triggers another render, which creates another params object, and so on forever. Fixes, best first: - Depend on primitives: create the object inside the effect and list [query] as the dependency. - If the object is needed elsewhere too, memoize it: useMemo(() => ({ q: query, limit: 20 }), [query]). - Move values that never change outside the component. The same trap appears with functions declared in the component body and used in the effect, and with an effect that updates state it also depends on, like setCount(count + 1) with [count]. Don't silence the lint rule to stop the loop; restructure so the dependencies are honest. While you're there, add a cleanup that ignores stale responses.

Question 35

What is a stale closure in React? Explain why this counter gets stuck at 1 and how to fix it.

Accepted Answer

Every render creates new functions that close over that render's props and state. A stale closure happens when a function created during an old render keeps running later and still reads that old snapshot.

Here the effect runs only once, so the interval callback captured count from the first render, where it's 0. Every tick calls setCount(0 + 1): the display goes to 1 and stays there.

Fixes:

Use an updater: setCount(c => c + 1) always receives the latest state, so the effect no longer needs count at all.
Add the value to the dependencies, so the effect re-subscribes with fresh values; here that restarts the interval on every change.
For a long-lived listener that must always see the latest props, keep the latest callback in a ref, or use useEffectEvent, added in React 19.2.

The exhaustive-deps lint rule flags most of these. The same bug shows up with useCallback and useMemo that have missing dependencies.

Question 36

Explain the difference between client-side rendering, server-side rendering and static site generation. What is hydration?

Accepted Answer

They differ in where and when the HTML is produced:

CSR: the server sends a nearly empty HTML shell plus a JavaScript bundle, and React builds the UI in the browser. Simple to host and fine for app-like dashboards, but nothing useful shows until the JavaScript loads, and crawlers see little content.
SSR: the server renders components to HTML on each request, so content appears quickly and SEO works. It costs server work per request, and the page isn't interactive until its JavaScript loads.
SSG: HTML is rendered at build time and served from a CDN. Fastest and cheapest; ideal for docs, blogs and marketing pages, but content is only as fresh as the last build.

Hydration follows SSR or SSG: React runs in the browser, renders the same components, and attaches event handlers and state to the existing HTML instead of recreating it, using hydrateRoot. The client's first render must match the server HTML. With Suspense, React can stream HTML and hydrate parts of the page independently.

Question 37

What are portals in React, and when would you use one?

Accepted Answer

createPortal(children, domNode) from react-dom renders children into a different DOM node, often one directly under document.body, while keeping them at the same place in the React tree. Typical uses are modals, tooltips, dropdown menus and toasts. A modal rendered deep inside a card with overflow: hidden, or inside a stacking context created by z-index or transform, gets clipped or layered incorrectly. A portal moves the DOM output out of that container, while you still write the modal right next to the button that opens it. Because a portal stays in the React tree: - it still receives context from its React ancestors, - events bubble through React ancestors, not DOM ancestors, so a click inside the modal also triggers onClick handlers on the components that render it, which can be surprising. For accessibility you still need focus management, closing on Escape and the right ARIA roles; the native dialog element is a good alternative for modals.

Question 38

What was forwardRef used for, and what changed about passing refs to components in React 19?

Accepted Answer

Before React 19, ref was a special attribute that React removed from props, so a function component couldn't receive it. If a parent wrote <TextInput ref={inputRef} /> to focus the inner input, TextInput had to be wrapped in forwardRef, which passed the ref as a second argument that the component forwarded onto a DOM element. In React 19, function components can read ref directly as a prop: function TextInput({ ref, ...props }). forwardRef still works but is no longer needed, and the React team has said it will be deprecated in a future version. For class components nothing changed: a ref on a class component still points to the instance and isn't passed as a prop. Related tools: useImperativeHandle lets a component expose a limited API, like { focus, scrollToTop }, instead of the whole DOM node, and in React 19 a ref callback can return a cleanup function.

Question 39

In development, your effect connects to a chat server twice when the component mounts. Is this a React bug, and what should you do?

Accepted Answer

It's not a bug. In development, <StrictMode> mounts each component, runs its effects, then simulates an unmount by running the cleanups, and runs the effects again. It does this deliberately, to reveal effects that don't clean up after themselves. It never happens in production builds. So the double connection is telling you the effect is missing a correct cleanup. Make setup and cleanup symmetric: if the effect calls connection.connect(), the cleanup must call connection.disconnect(). Then connect, disconnect, connect looks the same to the user as a single connect. The same goes for subscriptions (unsubscribe), timers (clear) and fetches (abort, or ignore the stale result). Don't work around it with a "has already run" ref: that hides the symptom but keeps the bug, and React can legitimately remount components while preserving their state. For logic that must run exactly once when the app starts, put it at module level, outside any component.

Question 40

A tooltip first appears in the wrong position and then jumps into place. Why does this happen, and how would you fix it?

Accepted Answer

The tooltip probably measures itself in a useEffect and then stores its position in state. useEffect usually runs after the browser paints, so the user sees one frame of the tooltip in its initial position; then the effect measures, sets state, and a second paint moves it.

The fix is useLayoutEffect. It runs after React has updated the DOM but before the browser paints. You read layout with getBoundingClientRect(), set state, and React processes that update before the screen is painted, so the user only ever sees the final position.

Caveats:

It blocks painting, so keep the work small and use it only when you must measure before showing something.
It doesn't run during server rendering, so the server HTML won't include the measured values.
A positioning library like Floating UI already handles this, including flipping and collision detection.

Default to useEffect, and switch to the layout version only for this kind of visual measurement.

Question 41

In class components, why did event handlers need this.handleClick = this.handleClick.bind(this), and why is that unnecessary in function components?

Accepted Answer

In JavaScript, this is determined by how a function is called, not where it's defined. onClick={this.handleClick} passes the method as a bare function reference. When React later calls it, there's no object before the dot, so this is undefined (class bodies always run in strict mode) and this.setState throws a TypeError. The classic fixes: - Bind once in the constructor: this.handleClick = this.handleClick.bind(this). - Use a class field arrow function, handleClick = () => { ... }, because arrow functions capture this lexically from the instance. - Use an inline arrow, onClick={() => this.handleClick()}, which creates a new function on every render. Function components avoid the problem entirely, because there is no this. Handlers are ordinary functions declared inside the component that close over the current render's props and state. The trade-off shifted from binding bugs to being aware of stale closures, but the code is simpler.

Question 42

Why would you use a library like TanStack Query instead of fetching data in useEffect?

Accepted Answer

Fetching in an effect looks simple, but a production-quality version needs a lot: loading and error states, ignoring stale responses when inputs change, caching so revisiting a screen is instant, deduplicating identical requests from several components, refetching stale data, retries, pagination, and refreshing data after a mutation.

Server data isn't really client state; it's a cache of something the server owns. TanStack Query, SWR, RTK Query and Apollo (for GraphQL) are built around that idea. You call useQuery with a queryKey and a queryFn, and get back data, error and status flags. The key identifies the cache entry, so every component asking for the same key shares one request and one cached result. After a write, useMutation plus invalidateQueries refetches the affected data.

Effects also create request waterfalls: a child can't start fetching until its parent has rendered. Frameworks avoid that by fetching in route loaders or Server Components, the other good alternative.

Question 43

What is concurrent rendering in React, and which APIs let you take advantage of it?

Accepted Answer

Before React 18, once React started rendering an update it had to finish synchronously, so a big render could block typing and clicks. Concurrent rendering makes rendering interruptible: React can start rendering an update, pause to handle something more urgent, and then resume, restart or throw away the unfinished work. Changes are committed only when a render completes, so users never see half-finished UI.

It's opt-in per update rather than a global mode, and it requires createRoot. The APIs:

startTransition and useTransition mark a state update as non-urgent; urgent updates like typing interrupt it, and isPending lets you show feedback.
useDeferredValue renders with a lagging copy of a value, then catches up in the background.
<Suspense> with transitions keeps the previous UI on screen instead of showing a fallback while new content loads.

Concurrency doesn't make rendering itself faster; it changes scheduling so the app stays responsive. It's also why render functions must be pure: a render may run more than once before it's committed.

Question 44

What are the key differences between React and Angular?

Accepted Answer

The main differences: - Scope: React is a UI library; routing, data fetching and forms come from the ecosystem or a framework like Next.js. Angular is a full, opinionated framework with a router, HTTP client, forms, dependency injection and a CLI built in. - Templates: React uses JSX, so markup lives in JavaScript and you loop with map. Angular uses HTML templates with its own syntax, such as @if, @for and property and event bindings. - Data flow and reactivity: React has one-way data flow and re-renders components when state changes. Angular also supports two-way binding with [(ngModel)] and updates the view through change detection, increasingly driven by signals. - Language: React works with JavaScript or TypeScript; Angular is TypeScript-first. - Architecture: Angular has services and dependency injection built in; React shares logic through hooks and context. Neither is better overall. React offers flexibility and a huge ecosystem, but teams must choose libraries and conventions. Angular offers consistency out of the box, which suits large teams, at the cost of a steeper learning curve.

Question 45

What is React Fiber, and what problem did it solve?

Accepted Answer

Fiber is the reconciliation engine React has used since React 16, a rewrite of the older "stack" reconciler. The old reconciler walked the component tree recursively and synchronously, so a large update couldn't be paused and could block the main thread.

Fiber represents each component instance, DOM element or fragment as a fiber: a plain object holding its type, props, state and hooks, pending work, and pointers to its child, sibling and parent. Because traversal is a loop over these linked nodes rather than deep recursion, React can split rendering into small units of work, pause between them to yield to the browser, prioritize urgent updates, and resume or discard work.

React keeps two trees: the current tree that's on screen and a work-in-progress tree being built, swapped on commit. The render phase is interruptible; the commit phase is synchronous, so the DOM never shows a partial update.

Fiber is the foundation for error boundaries, Suspense, transitions and concurrent rendering. It's an internal implementation detail you don't use directly.

Question 46

How would you render a list of 10,000 rows without the page becoming sluggish?

Accepted Answer

The main technique is virtualization, also called windowing: render only the rows visible in the viewport, plus a small overscan buffer, instead of all 10,000. The scroll container keeps the full list height through a spacer or padding, and rows are positioned by index, so as you scroll the same few dozen DOM nodes are reused with new data. Libraries include TanStack Virtual, react-window and react-virtuoso, which handles variable heights well. Supporting measures: - Stable keys and memo on the row component, so scrolling doesn't re-render every visible row. - Keep filtering and sorting cheap with useMemo, and use useDeferredValue for the search query. - Consider pagination or infinite loading if users don't need everything at once. Trade-offs worth mentioning: variable row heights need measuring, the browser's find-in-page can't see rows that aren't rendered, and screen readers need extra ARIA hints about the total size. For moderately long pages, CSS content-visibility: auto is a lighter alternative.

Question 47

What are the render and commit phases, and why must components be pure during rendering?

Accepted Answer

React splits an update into a render phase, where it calls your components to compute JSX, and a commit phase, where it applies the changes to the DOM and then runs effects. Rendering is treated as a pure calculation: given the same props, state and context, a component should return the same JSX and change nothing outside itself. React relies on this because a render isn't guaranteed to be committed. With concurrent features, React may start, pause, discard or repeat a render, and StrictMode renders twice in development precisely to expose impure components. Side effects that don't belong in render: - mutating props, state, or variables defined outside the component, - touching the DOM, localStorage or a global cache, - starting fetches, subscriptions or timers, - reading or writing ref.current, except for lazy initialization. Mutating an object you created during the same render is fine; that's local mutation. Side effects belong in event handlers, or in effects when they synchronize with an external system. Purity is also what lets the React Compiler memoize safely.

Question 48

How do you reset a component's internal state when a prop such as userId changes?

Accepted Answer

React preserves a component's state as long as the same component type renders at the same position in the tree. So when <Profile userId={id} /> receives a new id, its internal state, such as a half-typed comment, is kept, which is often a bug.

The idiomatic fix is a key: <Profile key={userId} userId={userId} />. When the key changes, React treats it as a different component: it unmounts the old instance, discarding its state and all of its children's state, and mounts a fresh one. No effect is needed.

Avoid resetting state in a useEffect that watches the prop: the component first renders with the stale state and then again after the reset, and you have to remember to reset every piece of state. If only part of the state should reset, it's usually cleaner to restructure, for example by storing a selected id instead of a copied object, so the value is derived during render.

Question 49

What does the 'use client' directive do? Does it mean the component only renders in the browser?

Accepted Answer

No, and that's a common misconception. In an app using React Server Components, like the Next.js App Router, components are Server Components by default. 'use client' at the top of a file marks a boundary: that module, and every module it imports, becomes part of the client bundle, so its components can use state, effects, event handlers and browser APIs.

Client Components are still pre-rendered to HTML on the server and then hydrated in the browser. "Client" means the code also ships to and runs in the browser, not that the server skips it. That's why browser-only APIs like window still belong in effects or event handlers.

Other details:

It must come first in the file, before any imports.
It follows the import graph, not the render tree: a Server Component passed as children to a Client Component stays on the server.
Props passed from Server to Client Components must be serializable, so no regular functions.
Place it as low as possible, on interactive leaves, to keep the bundle small.

Question 50

How does React protect against XSS, and what are the risks of dangerouslySetInnerHTML?

Accepted Answer

By default React escapes strings rendered in JSX:

{comment}

inserts the value as text, so an injected

React

Notes in this chapter

useEffect Pitfalls Interviewers Love to Ask

React Reconciliation & Keys: What Really Happens

memo, useMemo and useCallback: When They Actually Help

Top 77 React interview questions most asked first