Effects are for synchronization

An effect is an escape hatch out of React’s render flow — it exists to reach a system React doesn’t control. Rendering is pure: given props and state, you describe UI, and React owns the rest. But the real world has things React knows nothing about — network sockets, document.title, localStorage, an imperative chart instance, the IntersectionObserver API. An effect is the sanctioned way to step outside render, touch that external thing, and keep it in step with your component’s current state.

// the canonical shape: set up the external system, return its teardown
useEffect(() => {
  const connection = createConnection(roomId);   // step outside React
  connection.connect();
  return () => connection.disconnect();           // tear down on cleanup
}, [roomId]);                                      // re-sync when roomId changes

Read that dependency array as “re-synchronize whenever roomId changes”, not “run this when roomId changes”. The framing matters: an effect synchronizes; it doesn’t react.

A correct effect always describes a two-way contract: set up, and tear down. The cleanup function isn’t optional politeness — it’s half the pattern. React may run your effect, then later re-run it (deps changed) or unmount the component, and every setup must have a matching teardown or you leak. A subscription with no unsubscribe, a setInterval with no clearInterval, an event listener never removed — each one accumulates across renders and remounts.

function ChatRoom({ roomId }: { roomId: string }) {
  useEffect(() => {
    const socket = new WebSocket(`wss://chat.example.com/${roomId}`);
    const onMessage = (e: MessageEvent) => console.log(e.data);
    socket.addEventListener("message", onMessage);
    return () => {
      socket.removeEventListener("message", onMessage);
      socket.close();                              // teardown mirrors setup exactly
    };
  }, [roomId]);
  return <div>Room: {roomId}</div>;
}

In React 19’s Strict Mode, the effect is intentionally run setup→cleanup→setup in development to surface a missing teardown immediately. If your effect breaks under that double-invoke, the cleanup is wrong — that’s the test doing its job, not a bug to suppress.

Synchronizing with a browser API is the same pattern — even when it looks like “just set a value”. Setting document.title from your component’s state is a synchronization: document is an external system, and you’re keeping it in step with React state. It belongs in an effect, and (because the title persists) it ideally restores on cleanup.

function PageTitle({ unread }: { unread: number }) {
  useEffect(() => {
    const previous = document.title;
    document.title = unread > 0 ? `(${unread}) Inbox` : "Inbox";
    return () => { document.title = previous; };   // restore on unmount
  }, [unread]);
  return null;
}

The tell that this is a real effect: the target (document.title) is not React state, not a prop, not JSX. You are reaching out of the render tree to mutate the world. That’s the whole license for an effect to exist.

The dominant failure mode: an effect used to compute derived data from props or state. This is the misuse that produces most “my effect bugs out” reports. The reasoning feels right — “when items or query changes, recompute filtered” — so people write an effect that sets a second state variable. But there is no external system here. filtered is a pure function of items and query; computing it during render is correct, synchronous, and bug-free. The effect version introduces an extra render, a second source of truth, and a window where the screen shows stale data.

// WRONG: no external system — this is derived data wearing an effect costume
const [filtered, setFiltered] = useState<Item[]>([]);
useEffect(() => {
  setFiltered(items.filter((i) => i.name.includes(query)));
}, [items, query]);                                // extra render + can show stale data

// RIGHT: compute during render; no effect, no second state, never stale
const filtered = items.filter((i) => i.name.includes(query));
// (wrap in useMemo only if the filter is genuinely expensive)

The heuristic: before writing an effect, name the external system it synchronizes with. “It synchronizes with… filtered” is not an external system — it’s React state, and the effect must be deleted.