🔄 useEffect Hook for Side Effects

What Is a Side Effect?

A React component's job is to take props and state and return JSX — nothing more. That calculation should be pure: no network calls, no timers, no writing to document.title, no reaching into the DOM. Purity is what lets React re-run your component freely and trust the result.

A side effect is any operation that steps outside that pure calculation to interact with the world beyond the component:

• Fetching data from an API
• Subscribing to a WebSocket, event emitter, or browser event
• Setting timers with setTimeout / setInterval
• Manually reading or writing the DOM (focus, scroll, measurements)
• Logging, analytics, or syncing to localStorage

💡 A useful analogy: Your main job while cooking dinner is preparing the meal (rendering). But the doorbell rings, a timer goes off, the phone buzzes — errands that aren't cooking but still have to happen (side effects). useEffect is the note on the fridge that says "after each time you plate the food, run these errands."

Because effects run after render, they never block the user from seeing the UI, and React can synchronize them with your component's lifecycle in a predictable way.

Syntax & the Dependency Array

useEffect takes two arguments: a setup function containing the effect, and an optional dependency array that tells React when to re-run it.

import { useState, useEffect } from 'react';

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

  useEffect(() => {
    // The side effect: sync the browser tab title to state
    document.title = `You clicked ${count} times`;

    // Optional cleanup: restore the title when the effect is torn down
    return () => {
      document.title = 'React App';
    };
  }, [count]); // Re-run only when `count` changes

  return (
    <button onClick={() => setCount(c => c + 1)}>
      Clicked {count} times
    </button>
  );
}

The three flavors of dependency array

The dependency array is the single most important part of useEffect. It answers one question: "which values, if they change, should make this effect run again?"

Cleanup: Preventing Leaks

If your effect creates something that outlives a single render — an event listener, a timer, a subscription — you must tear it down. Return a cleanup function from the effect and React will call it before the next run and before unmount.

import { useState, useEffect } from 'react';

function WindowSize() {
  const [size, setSize] = useState({
    width: window.innerWidth,
    height: window.innerHeight,
  });

  useEffect(() => {
    const handleResize = () => {
      setSize({ width: window.innerWidth, height: window.innerHeight });
    };

    window.addEventListener('resize', handleResize);

    // Cleanup: remove the listener so it doesn't pile up
    return () => window.removeEventListener('resize', handleResize);
  }, []); // Set up once, tear down on unmount

  return <p>{size.width} × {size.height}</p>;
}

A subtle but important detail: each effect run gets its own cleanup. The cleanup closes over the values from the render that created it, so it always removes exactly the listener it added — never a mismatched one.

Timers are the textbook case

function Stopwatch() {
  const [seconds, setSeconds] = useState(0);
  const [running, setRunning] = useState(false);

  useEffect(() => {
    if (!running) return; // No timer needed while paused

    const id = setInterval(() => {
      // Functional update: no need to list `seconds` as a dependency
      setSeconds(s => s + 1);
    }, 1000);

    return () => clearInterval(id); // Stop the old interval before restarting
  }, [running]);

  return (
    <div>
      <p>{seconds}s</p>
      <button onClick={() => setRunning(r => !r)}>
        {running ? 'Pause' : 'Start'}
      </button>
    </div>
  );
}

Notice the functional update setSeconds(s => s + 1). Because it reads the latest state from React rather than from the closure, we don't have to put seconds in the dependency array — which would otherwise recreate the interval every tick.

Data Fetching & Race Conditions

Fetching in an effect is common, but there's a trap. If a prop like userId changes quickly, an older request can resolve after a newer one, overwriting fresh data with stale data. This is a race condition.

The fix is to mark the effect as "ignored" during cleanup, or to cancel the request with an AbortController:

import { useState, useEffect } from 'react';

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [status, setStatus] = useState('loading'); // 'loading' | 'error' | 'ready'

  useEffect(() => {
    let ignore = false;           // Guards against out-of-order responses
    const controller = new AbortController();
    setStatus('loading');

    async function load() {
      try {
        const res = await fetch(`/api/users/${userId}`, {
          signal: controller.signal,
        });
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        const data = await res.json();
        if (!ignore) {
          setUser(data);
          setStatus('ready');
        }
      } catch (err) {
        if (err.name !== 'AbortError' && !ignore) setStatus('error');
      }
    }

    load();

    // Cleanup: this render's fetch is now stale — ignore it and abort
    return () => {
      ignore = true;
      controller.abort();
    };
  }, [userId]);

  if (status === 'loading') return <p>Loading…</p>;
  if (status === 'error') return <p>Could not load user.</p>;
  return <h2>{user.name}</h2>;
}

Common Pitfalls

1. The infinite loop

An effect that updates a value it also depends on will re-run forever:

// ❌ Infinite loop: setting `count` re-triggers the effect that sets `count`
useEffect(() => {
  setCount(count + 1);
}, [count]);

Fix it by removing the dependency (run once), using a functional update, or guarding with a condition:

// ✅ Runs once
useEffect(() => {
  setCount(1);
}, []);

2. Lying about dependencies

Leaving a value out of the array to "make it run less" creates a stale closure — the effect captures an old value and silently misbehaves. Include everything the effect reads, and let the eslint-plugin-react-hooks rule check you.

3. Reaching for useEffect when you don't need it

Modern React guidance: you might not need an effect. Data you can compute during render (a filtered list, a derived total) should be computed directly — not stored in state and synced with an effect. Save useEffect for genuine outside-the-component synchronization.

Hands-on: Live Search with Debounce

import { useState, useEffect } from 'react';

function LiveSearch() {
  const [term, setTerm] = useState('');
  const [debounced, setDebounced] = useState('');
  const [results, setResults] = useState([]);
  const [loading, setLoading] = useState(false);

  // Effect 1 — debounce the raw input
  useEffect(() => {
    const id = setTimeout(() => setDebounced(term), 400);
    return () => clearTimeout(id); // cancel on the next keystroke
  }, [term]);

  // Effect 2 — fetch when the debounced term settles
  useEffect(() => {
    if (!debounced.trim()) {
      setResults([]);
      return;
    }

    let ignore = false;
    const controller = new AbortController();
    setLoading(true);

    async function search() {
      try {
        const res = await fetch(
          `https://api.github.com/search/users?q=${encodeURIComponent(debounced)}`,
          { signal: controller.signal }
        );
        const data = await res.json();
        if (!ignore) setResults(data.items ?? []);
      } catch (err) {
        if (err.name !== 'AbortError' && !ignore) setResults([]);
      } finally {
        if (!ignore) setLoading(false);
      }
    }

    search();
    return () => {
      ignore = true;
      controller.abort();
    };
  }, [debounced]);

  return (
    <div>
      <input
        value={term}
        onChange={(e) => setTerm(e.target.value)}
        placeholder="Search GitHub users…"
      />
      {loading && <p>Searching…</p>}
      <ul>
        {results.map((u) => (
          <li key={u.id}>{u.login}</li>
        ))}
      </ul>
    </div>
  );
}

Best Practices

Summary & Quiz

📚 Further Reading

• React docs — useEffect reference
• React docs — Synchronizing with Effects
• React docs — You Might Not Need an Effect

🚀 What's Next?

When state grows tangled — many interrelated fields, many ways to update it — scattered useState calls become hard to reason about. Next we'll centralize that logic with useReducer, a structured, testable way to manage complex state.