Component Lifecycle

1Three Phases, Not a List of Methods

Every component instance goes through the same three phases, regardless of whether it's written as a class or a function:

1. Mount — the component is created and its output is inserted into the DOM for the first time.
2. Update — the component re-renders because its props, state, or a context it reads changed (see "Rendering and reconciliation" for exactly what triggers this).
3. Unmount — the component is removed from the tree and its DOM node is torn down.

Class components exposed these phases as named methods you override. Function components don't have named lifecycle methods at all — useEffect (and friends) let you attach behavior to phases by describing when an effect should re-run, not by naming the phase directly. Both are two different APIs over the exact same underlying phases, produced by the exact same commit-phase mechanics (see section 6).

2The Class Component Lifecycle

class UserProfile extends React.Component<{ userId: string }, { user: User | null }> {
  constructor(props: { userId: string }) {
    super(props);
    this.state = { user: null }; // set up initial state — runs once, before mount
  }

  componentDidMount() {
    // runs once, right after the component's DOM node is inserted
    fetchUser(this.props.userId).then((user) => this.setState({ user }));
  }

  componentDidUpdate(prevProps: { userId: string }) {
    // runs after every re-render EXCEPT the first — always compare props/state
    // yourself, since this fires on every update, not just the relevant one
    if (prevProps.userId !== this.props.userId) {
      fetchUser(this.props.userId).then((user) => this.setState({ user }));
    }
  }

  componentWillUnmount() {
    // runs once, right before the DOM node is removed — cancel subscriptions,
    // timers, in-flight requests here
    this.pendingRequest?.cancel();
  }

  render() {
    return this.state.user ? <p>{this.state.user.name}</p> : <p>Loading…</p>;
  }
}

Note the shape all three share: render is called to compute what to show, and componentDidMount/componentDidUpdate/componentWillUnmount are called around it to run side effects tied to when it happened. This is the split hooks eventually generalized.

3The Function-Component Equivalent: useEffect

function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);

  useEffect(() => {
    let cancelled = false;
    fetchUser(userId).then((u) => {
      if (!cancelled) setUser(u);
    });
    return () => {
      cancelled = true; // cleanup — this is componentWillUnmount's job, reused
    };
  }, [userId]); // re-run only when userId actually changes

  return user ? <p>{user.name}</p> : <p>Loading…</p>;
}

This one useEffect call replaces componentDidMount and componentDidUpdate and componentWillUnmount at once — see the mapping table in section 4. The full mechanics of the dependency array, cleanup timing, and common bugs are covered in depth in the "UseEffect" topic; this topic focuses on how that mapping lines up with the class model and the commit phase underneath both.

4The Mapping, Precisely

The important asymmetry: a single useEffect with a dependency array covers mount, every relevant update, and unmount cleanup — three class methods collapse into one hook because the hook is keyed on "did this value change," not on "which named phase are we in."

5Cleanup Runs Before the Next Effect, Not Just on Unmount

This is the detail that trips people coming from classes the hardest: the cleanup function isn't only for unmount. React runs it before every re-run of the effect, including ordinary updates — not just the final unmount.

useEffect(() => {
  const id = setInterval(() => console.log("tick"), 1000);
  return () => clearInterval(id); // runs before the NEXT effect AND on unmount
}, [intervalMs]);

If intervalMs changes, React runs the cleanup from the previous effect (clearing the old interval) before running the new effect (starting a new one with the updated delay) — in that order, every time. On final unmount, there is no "next effect" to run, so only the cleanup fires. This single rule is why useEffect can replace componentDidMount + componentDidUpdate + componentWillUnmount with one function: "clean up the old thing, then set up the new thing" describes an update, and "clean up the old thing, don't set anything up" describes an unmount — same cleanup call, different question of whether a following effect exists.

commit:
  mutation sweep   → DOM changes; componentWillUnmount + useLayoutEffect cleanup (bottom-up, sync)
  layout sweep     → useLayoutEffect setup, componentDidMount/Update            (sync, pre-paint)
  ── browser paints ──
  passive sweep    → useEffect setup; useEffect cleanup for unmounted trees too  (async, post-paint)

⚠️ Common Pitfalls

1. Expecting componentDidUpdate (or a bare useEffect(fn) with no dependency array) to run only when "the relevant thing" changed — componentDidUpdate fires after every update regardless of cause, and an effect with no dependency array runs after every single render. Both require you to compare old vs. new yourself, or supply a dependency array, if you only care about specific changes.
2. Putting side effects directly in the render/component body instead of componentDidMount/useEffect** — the render phase (or a function component's body) can run more than once per commit or be thrown away entirely (see "Rendering and reconciliation"); only commit-phase hooks are guaranteed to run exactly once per actual DOM update.
3. Forgetting componentWillUnmount/effect cleanup entirely — subscriptions, intervals, and event listeners set up in componentDidMount/useEffect keep running (and keep references alive) after the component is gone, unless you tear them down in the matching cleanup.
4. Missing a dependency in useEffect's array — the effect keeps closing over a stale value from whatever render created it (this is the JavaScript Closures topic's "closures capture variables, not values" playing out inside a hook); the effect doesn't magically see updated outer variables just because they changed elsewhere.
5. Assuming cleanup only runs on unmount — as section 5 explains, it runs before every subsequent effect re-run too; code that assumes "this only happens once, at the very end" will run far more often than expected for a changing dependency.
6. Calling setState unconditionally inside componentDidUpdate without a guard — since componentDidUpdate fires after every update including the one this setState itself causes, an unguarded call creates an infinite re-render loop. The functional equivalent, an unconditional setState inside useEffect with no dependency array, has the identical failure mode.

📋 Quick Reference

useEffect(() => {
  setup();
  return () => cleanup(); // runs before next effect, AND on unmount
}, [deps]);

deps omitted   -> runs after every render (mount + every update)
deps = []      -> runs once, after mount only
deps = [a, b]  -> runs after mount, and after any render where a or b changed
                  (Object.is comparison, element by element)

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: react_component_lifecycle_theory.md · generated by tools/build_lessons.py