useEffect & the Dependency Array

Reviewed & published by Brayan K

useEffect lets a component run side effects — work that reaches outside React, like setting the document title, starting a timer, or subscribing to something — after it renders. The second argument, the dependency array, controls exactly when the effect re-runs, and the function it returns handles cleanup.

Part of the free React course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

What You'll Learn

• What a side effect is and why it goes in useEffect
• How the dependency array decides when the effect re-runs
• The difference between [], [dep], and no array at all
• When and how the effect runs in the render lifecycle
• Writing a cleanup function to avoid leaks
• Why effects can run twice in development (Strict Mode)

1️⃣ The Dependency Array Controls When It Runs

After each render, React compares every value in the dependency array to its value from the previous render. If any changed, the effect runs again. Three shapes you'll use constantly:

useEffect(() => { /* ... */ });          // no array  -> runs after EVERY render
useEffect(() => { /* ... */ }, []);      // empty     -> runs ONCE (after first render)
useEffect(() => { /* ... */ }, [count]); // [count]   -> runs when count changes

// React compares each dependency to its value LAST render.
// If any changed, the effect runs. Let's simulate that comparison.

function shouldRun(prevDeps, nextDeps) {
  // runs if ANY dependency changed
  return nextDeps.some((dep, i) => dep !== prevDeps[i]);
}

console.log(shouldRun([0], [0]));   // false  -> deps same, skip effect
console.log(shouldRun([0], [1]));   // true   -> count changed, run effect
console.log(shouldRun([1, "a"], [1, "b"]));   // true  -> second dep changed

// Empty deps [] never change, so [] vs [] is always "false" after mount:
console.log(shouldRun([], []));     // false  -> run once, then never again

Your turn — write the comparison React uses for a single dependency. It should be true only when the value changed:

// 🎯 YOUR TURN — fill in each ___ then press "Try it Yourself".
// Decide whether the effect should re-run. It re-runs when the
// "count" dependency CHANGED between renders.

function shouldRun(prevCount, nextCount) {
  // 1) Return true only when the value changed.
  return ___;        // 👉 compare prevCount and nextCount
}

console.log(shouldRun(0, 0));   // expect false
console.log(shouldRun(0, 1));   // expect true
console.log(shouldRun(5, 5));   // expect false

// ✅ Expected output:
//    false
//    true
//    false

2️⃣ Effects Run After the Browser Paints

React renders your component (computing JSX), lets the browser paint, and then runs your effects. That ordering is why effects never block the visible update — and why you read fresh DOM measurements or set the title after render, not during it.

// ORDER OF EVENTS: React renders, paints the screen, THEN runs effects.
const log = [];

function render() { log.push("1. render (compute JSX)"); }
function paint()  { log.push("2. browser paints screen"); }
function effect() { log.push("3. effect runs (side effect)"); }

render();
paint();
effect();

log.forEach(line => console.log(line));
// 1. render (compute JSX)
// 2. browser paints screen
// 3. effect runs (side effect)
// Effects run AFTER paint, so they never block the visible update.

3️⃣ Cleanup — Undo Before You Redo

If your effect starts something that keeps running — a timer, an event listener, a subscription — you must stop it. Return a function from the effect; React runs it before the next effect and when the component unmounts.

useEffect(() => {
  const id = setInterval(tick, 1000);   // setup: start the timer
  return () => clearInterval(id);       // cleanup: stop it
}, []);                                 // start once, stop on unmount

// CLEANUP: the function you return runs before the next effect
// and on unmount. Watch the order across two "renders".

const log = [];
function effect(id) {
  log.push("setup " + id);            // e.g. start a timer
  return () => log.push("cleanup " + id);  // stop that timer
}

const cleanup1 = effect(1);   // first render: setup 1
cleanup1();                   // before re-running: cleanup 1
const cleanup2 = effect(2);   // re-render: setup 2
cleanup2();                   // unmount: cleanup 2

log.forEach(line => console.log(line));
// setup 1
// cleanup 1
// setup 2
// cleanup 2

🧩 Reorder Challenge

These lines form a complete effect that subscribes to a timer and cleans it up. Put them in the right order:

A.   const id = setInterval(tick, 1000);
B.   useEffect(() => {
C.   }, []);
D.   return () => clearInterval(id);

Common Errors (and the fix)

• Infinite loop / "Maximum update depth exceeded". — Your effect sets state but has no deps (or a dep that the effect itself changes). Add a correct dependency array and avoid setting state unconditionally.
• Stale data inside the effect. — A value you read isn't in the deps array, so the effect kept the old closure. Add every reactive value it uses to the array.
• Timer / listener keeps firing after unmount. — You forgot the cleanup. Return a function that clears or removes it.

Pro Tips

• 💡 List every reactive value the effect reads in the deps array — let the lint rule guide you, don't fight it.
• 💡 One effect per concern. Don't cram unrelated work into one effect; split them so their deps stay clean.
• 💡 Not everything needs an effect. If you can compute a value during render, do that instead of syncing it in an effect.

📋 Quick Reference

🧠 Quick Recall

1. An effect has deps []. The component re-renders 5 times. How many times does the effect run?

Once. An empty array never changes, so the effect runs only after the first render.

2. You write useEffect(() => setN(n + 1)) with no deps array. What happens?

Infinite loop. It runs after every render, sets state, which re-renders, which runs it again.

3. In what order do render, paint, and the effect happen?

Render → paint → effect. Effects run after the screen is painted.

Mini-Challenge: Title-Only-On-Change

Model an effect with [count]: it should "set the title" only when count actually changes. Run it and check your output.

// 🎯 MINI-CHALLENGE: model the document.title effect
//
// An effect with [count] updates the title only when count changes.
// 1. Start prevCount = null (first render always runs).
// 2. For each value in clicks, decide if the effect runs (value changed),
//    and if so push "Set title: " + value to results.
// 3. console.log every line in results.
//
// ✅ Expected output:
//    Set title: 0
//    Set title: 1
//    Set title: 3

const clicks = [0, 0, 1, 1, 3];
let prevCount = null;
const results = [];

// your code here

🎉 Lesson Complete

• ✅ useEffect runs side effects after render
• ✅ The dependency array decides when it re-runs: [] once, [dep] on change, omitted every time
• ✅ Effects run after the browser paints
• ✅ Return a cleanup function to stop timers, listeners, and subscriptions

Practice quiz

Continue this course

• Previous: Styling in React
• Next: Data Fetching with useEffect — Fetch data the right way — with loading and error states
• Quick reference: React cheat sheet › Effects & Data

Frequently asked questions

What does the dependency array actually do?

It tells React WHEN to re-run the effect. After every render, React compares each value in the array to its value last render; if any changed, the effect runs again. An empty array [] means 'never re-run after the first time'.

What happens if I omit the dependency array entirely?

The effect runs after EVERY render. That's rarely what you want and often causes infinite loops if the effect also sets state.

What is the cleanup function for?

Returning a function from useEffect lets React tear down the previous effect before re-running it and when the component unmounts. Use it to clear timers, remove event listeners, and cancel subscriptions so you don't leak resources.

Why does my effect run twice in development?

React 18 Strict Mode intentionally mounts, unmounts, and remounts components in development to surface missing cleanup. If your cleanup is correct, the double-run is harmless and does not happen in production.

Related lessons

• useState in Depth