React Lifecycle and useEffect Interview Questions

Mounting, when the component is added to the DOM; updating, when props or state change; and unmounting, when it is removed. React also has an error phase for components that catch errors from their children.

• Mounting. The component is created, rendered for the first time and inserted into the DOM.
• Updating. New props arrive or state changes, React re-renders and applies the difference.
• Unmounting. The component is removed, and anything it set up must be torn down.
• Error handling. A descendant throws during render, and an error boundary above it renders a fallback.

In a function component you do not name these phases. One useEffect with a cleanup covers setup on mount, re-synchronisation on update and teardown on unmount, which is deliberate: the three used to be written in three places and drift apart.

constructor, render and componentDidMount for mounting; shouldComponentUpdate, render and componentDidUpdate for updating; componentWillUnmount for unmounting; plus getDerivedStateFromError and componentDidCatch for errors.

One useEffect covers all three: an empty dependency array is mount, a populated array is update, and the returned cleanup function is unmount. The mapping is not exact, because effects synchronise rather than fire on lifecycle events.

// componentDidMount + componentWillUnmount
useEffect(() => {
  const socket = connect(roomId);
  return () => socket.close();
}, []);

// componentDidUpdate for a specific value
useEffect(() => {
  document.title = `${unread} unread`;
}, [unread]);

Track the first render with a ref and return early. There is no built-in option, and needing this often means the logic belongs in an event handler instead.

const isFirstRender = useRef(true);

useEffect(() => {
  if (isFirstRender.current) {
    isFirstRender.current = false;
    return;
  }
  onFilterChanged(filter);
}, [filter]);

Worth adding in an interview: if you are skipping the mount run because the effect is really "the user changed the filter", put the call in the change handler. You know there that a user action happened, which an effect can only infer.

Because React 18's StrictMode mounts, unmounts and remounts every component in development to check that your effects clean up after themselves. It does not happen in production.

The double invocation is a test, not a bug. An effect that survives it unchanged is an effect that will survive React reusing state in future features, and it is an effect that does not leak a subscription every time it re-runs.

useEffect(() => {
  const controller = new AbortController();

  fetch(url, { signal: controller.signal })
    .then((response) => response.json())
    .then(setData)
    .catch((error) => {
      if (error.name !== 'AbortError') setError(error);
    });

  return () => controller.abort();
}, [url]);

In the render phase React calls your components and builds the new tree; this work can be paused, restarted or thrown away, so it must be pure. In the commit phase React applies the changes to the DOM and runs refs and effects, and that cannot be interrupted.

• Render phase. Your component functions run, useMemo calculations run, the new element tree is diffed. No DOM is touched. With concurrent rendering React may run this twice or abandon it.
• Commit phase. React applies DOM mutations, then runs useLayoutEffect synchronously, then the browser paints, then useEffect runs.

This is why side effects during render are forbidden. A network request, a mutation of a module level variable or a document write in the render phase can happen twice or happen for a render that is never committed.

By default yes: React re-renders the whole subtree. Re-rendering means calling the component function and diffing, not touching the DOM, so it is usually cheap. React.memo skips a child whose props are unchanged.

Candidates often overstate the cost here. React re-running a function and comparing two small object trees is fast. The DOM is only touched where the diff found a difference, which is the point of the virtual DOM.

// Slow.js is re-rendered whenever Parent's state changes
function Parent() {
  const [n, setN] = useState(0);
  return <><button onClick={() => setN(n + 1)}>{n}</button><Slow /></>;
}

// Passing it in as children keeps the same element object, so React bails out
function Parent({ children }) {
  const [n, setN] = useState(0);
  return <><button onClick={() => setN(n + 1)}>{n}</button>{children}</>;
}

A stale closure is a callback that captured props or state from an old render and keeps reading those values after they have changed. It happens when a function outlives the render that created it, typically inside an interval, a subscription or an event listener registered once.

const [count, setCount] = useState(0);

useEffect(() => {
  const id = setInterval(() => {
    setCount(count + 1); // count is always 0
  }, 1000);
  return () => clearInterval(id);
}, []); // no dependency on count

The three fixes

1. Functional update. setCount((previous) => previous + 1) needs no captured value at all. Best when you only need the latest state.
2. Add the dependency. Let the effect tear down and re-run with fresh values. Correct, but restarts the interval every second here.
3. A ref holding the latest value. Keep a useRef updated in an effect and read ref.current inside the callback. Use this when the callback must be stable and still see current data.

In practice, with a data library such as TanStack Query, RTK Query or the framework's loader. If you must do it by hand, use an effect keyed on the request inputs, handle loading and error states, and cancel the request in the cleanup.

useEffect(() => {
  const controller = new AbortController();
  setStatus('loading');

  fetch(`/api/users/${id}`, { signal: controller.signal })
    .then((response) => {
      if (!response.ok) throw new Error(response.statusText);
      return response.json();
    })
    .then((data) => {
      setUser(data);
      setStatus('done');
    })
    .catch((error) => {
      if (error.name !== 'AbortError') setStatus('error');
    });

  return () => controller.abort();
}, [id]);

• The effect callback cannot be async, because it must return a cleanup function, not a promise. Define an async function inside and call it.
• fetch does not reject on a 404 or 500. Check response.ok yourself.
• Without cancellation you get race conditions: a slower earlier request can resolve last and overwrite newer data.
• In a framework, fetching on the server or in a route loader avoids the request waterfall an effect creates.

It is a static class lifecycle that returns a state update from incoming props before every render. It is discouraged because it duplicates the source of truth, and almost every use has a simpler solution: compute during render, or reset with a key.

It replaced componentWillReceiveProps and was deliberately made static so it cannot read this and cannot cause side effects. Even so, it is the API most often used to build the same bug: two copies of one value that drift apart.

• If the value can be computed from props, compute it in render, no state needed.
• If the component should start over when a prop changes, give it a different key and let React remount it.
• If you truly need to remember the previous prop to compare against, store the previous value in state alongside the derived value, which is the pattern the React docs describe.

shouldComponentUpdate lets a class return false to skip a re-render. PureComponent implements it for you with a shallow comparison of props and state. React.memo is the function component equivalent.

class Row extends React.PureComponent {  // shallow compare, then skip
  render() {
    return <li>{this.props.label}</li>;
  }
}

const Row = React.memo(function Row({ label }) {
  return <li>{label}</li>;
});

Render runs top down: parent first, then children. Effects run bottom up: children's effects fire before the parent's, because a parent's effect may depend on its children having mounted.

Parent render
Child render
Child useLayoutEffect
Parent useLayoutEffect
-- browser paints --
Child useEffect
Parent useEffect

Cleanup follows the same bottom up order on unmount. Knowing this matters when a parent measures a child in a layout effect: the child's DOM exists by then, which is exactly why layout effects run after the whole subtree has committed.