Lesson 4 of 80

useEffect

Q: Walk me through exactly when a useEffect callback runs, relative to render and the browser painting the screen — and why that timing matters.

A strong answer covers: Effects run after React commits the DOM update and after the browser paints, not during render; This is deliberate: render must stay a pure description of UI, and effects can't be allowed to block what the user sees; useLayoutEffect is the exception — it runs synchronously right after commit, before paint, at the cost of blocking.

The hook for side effects — anything that reaches outside the render itself, timed to run after the browser paints, not during render.

15 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 4

Relative to render and paint, when does a useEffect callback actually run?

After the DOM is committed and the browser has paintedDuring render, right after the component function returns its JSXBefore render, to set up any data the component needs

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on useEffect

What interviewers actually ask about this, and what a strong answer has to cover.

Walk me through exactly when a useEffect callback runs, relative to render and the browser painting the screen — and why that timing matters.

A strong answer covers

Effects run after React commits the DOM update and after the browser paints, not during render
This is deliberate: render must stay a pure description of UI, and effects can't be allowed to block what the user sees
useLayoutEffect is the exception — it runs synchronously right after commit, before paint, at the cost of blocking

Likely follow-ups

An effect reads a piece of state but doesn't list it in the dependency array — what actually goes wrong, concretely?
Why would you reach for useLayoutEffect instead of useEffect, and what's the real cost of doing so?
What does the cleanup function returned from an effect actually run before — only unmount, or something more often than that?
In plain vanilla JavaScript with no React, when does a direct DOM mutation like element.textContent = value actually take effect, compared to React's render → commit → paint → effect pipeline?

Practice these with the AI interviewer →

The plain-language idea

Rendering is supposed to be pure: given props and state, describe the UI, nothing else. But real components need to reach outside that — subscribe to something, fetch data, set a timer, measure the DOM. That's what useEffect is for: code that runs after React has committed and the browser has painted, deliberately kept separate from the render itself.

See it in a real thing: the order things actually happen in

function Clock() {
  const [now, setNow] = useState(Date.now());

  useEffect(() => {
    const id = setInterval(() => setNow(Date.now()), 1000);
    return () => clearInterval(id); // cleanup — runs before the next effect, and on unmount
  }, []); // empty array: run once, after the first paint

  return <p>{new Date(now).toLocaleTimeString()}</p>;
}

Render, commit, paint, effectStep 1 of 4

The component function runs and returns JSX — a description of UI. Nothing on screen has changed yet.

The dependency array ([] here) controls when the effect re-runs: [] means once, right after the first paint; [now] would mean "re-run whenever now changes"; omitting the array entirely means "run after every single render" — almost always a mistake.

What people usually miss

Watch out

Effects run after paint, not during render. That's why you can't read the result of an effect (like a fetched value) synchronously in the same render that triggered it — the effect hasn't run yet when the JSX is being computed.
An empty dependency array doesn't mean "runs once, period." It means "runs once after the first paint of this component instance." If the component unmounts and a new instance mounts later, its own effect runs again.
Forgetting a dependency is a real, common bug — an effect that reads count but doesn't list it in the dependency array keeps using whatever count was when the effect was created, the same stale-closure trap from the useState lesson.
useLayoutEffect exists for the rare case effect timing itself matters — it runs synchronously right after the DOM commit, before the browser paints. Good for DOM measurements that must never flash the wrong layout; bad for anything slow, since it blocks painting until it finishes.

Why this matters in interviews

"When does an effect actually run, relative to render and paint?" tests whether you understand effects as reactions to a completed render, not part of the render itself — and it's the exact question that explains why effects can safely touch the DOM or start a subscription when the render function itself can't.