Understanding useEffect Dependencies and Cleanup

Part 1: The Dependency Array - Controlling Effect Execution

Let's start with a common scenario: fetching data when a component mounts. A naive implementation might look like this:

function UserProfile({ id }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`https://api.example.com/users/${id}`)
      .then(res => res.json())
      .then(data => setUser(data));
  }); // No dependency array!

  // ... render user data
}

What happens here?

1. The component renders.
2. useEffect runs, fetching data and calling setUser.
3. The state update from setUser triggers a re-render.
4. The component re-renders, and since there's no dependency array, useEffect runs again.
5. This creates an infinite loop of fetching and re-rendering.

This demonstrates the fundamental purpose of the dependency array: to tell React when to re-run an effect.

To understand how to control this, let's watch a video that walks through this exact problem and its solution.

As the video showed, the dependency array gives us precise control. Here’s a summary of its behavior:

• No dependency array: useEffect(callback) runs after every single render.
• Empty dependency array: useEffect(callback, []) runs only once, after the initial render (on mount).
• Populated dependency array: useEffect(callback, [dep1, dep2]) runs on mount, and then only if any of the dependencies have changed since the last render.

How React Checks Dependencies Under the Hood

This is where your interest in internal mechanics comes into play. How does React know if a dependency has "changed"?

When useEffect runs, React stores the dependency array you provided. On the next render, it gets the new dependency array and compares each value in the new array to the corresponding value in the old one, one by one.

The comparison is done using the Object.is() algorithm. This is very similar to a strict equality check (===), but it correctly handles a few edge cases (like NaN being equal to NaN).

This has a critical implication that often trips up developers:

• Primitive values (strings, numbers, booleans) are compared by value. 5 is always equal to 5.
• Reference types (objects, arrays, functions) are compared by reference. A new object { id: 1 } is not equal to another { id: 1 } because they are different objects in memory, even if their contents are identical.

This distinction is crucial for performance and bug prevention. Let's return to the video to see a fantastic explanation of this concept.

To reinforce this, let's briefly look at a simplified, reverse-engineered implementation of useEffect. This will connect back to what we learned about useState and the internal array of hooks.

Part 2: The Cleanup Function

Now that we can control when an effect runs, we need to address what happens when it's no longer needed. This is the job of the cleanup function.

A cleanup function is a function that you can optionally return from your effect's callback.

useEffect(() => {
  // Side effect logic goes here.
  // ...

  // Return a cleanup function.
  return () => {
    // Cleanup logic goes here.
  };
}, [/* dependencies */]);

When Does the Cleanup Function Run?

This is a frequently misunderstood topic. The cleanup function is called in two key circumstances:

1. When the component unmounts: React will run the cleanup to tidy up any lingering effects.
2. Before the effect runs again: If a dependency has changed and the effect is scheduled to re-run, React will first run the cleanup function from the previous render before executing the new effect.

This "cleanup-then-rerun" cycle is essential for keeping effects isolated and preventing bugs.

Use Case 1: Preventing Memory Leaks

The most common use case for cleanup is managing subscriptions or event listeners. If you add an event listener in useEffect but never remove it, you create a memory leak. Even if the component unmounts, the listener remains in memory, holding a reference to your component and preventing it from being garbage collected.

Use Case 2: Preventing Race Conditions

A more subtle but critical use for the cleanup function is preventing race conditions with asynchronous operations, like the fetch calls we discussed earlier.

Consider this scenario:

1. Your component renders with id: 1. The effect fetches user 1. This request is slow.
2. Before the first fetch completes, the user clicks a button, and the component re-renders with id: 2. The effect re-runs and fetches user 2. This request is fast.
3. The fetch for user 2 completes, and the state is set to user: 2. The UI correctly shows user 2.
4. A moment later, the slow fetch for user 1 finally completes. It calls setUser with user 1's data, overwriting the correct state. Now your UI is incorrectly showing user 1, even though the component's id prop is 2.

The cleanup function solves this elegantly. The following article provides an excellent explanation of this problem and its solution.

As the article demonstrates, you can use a boolean flag like isCurrent or isCancelled inside your effect. The cleanup function sets this flag to false. The async callback checks this flag before setting state. When the cleanup for the old effect runs, it "disarms" the old fetch call, preventing it from setting state when it eventually resolves.

The Big Picture: Effects in the Render/Commit Cycle

To complete your mental model, let's place useEffect within the render/commit cycle we've discussed.

In essence, React performs a carefully orchestrated dance:

1. Render Phase: Your component function runs. React sees the useEffect call, compares the new dependencies to the old ones, and if they've changed, it schedules the effect to run.
2. Commit Phase: React updates the actual DOM. The user sees the changes on the screen.
3. Post-Commit: Only after the browser has painted the changes does React execute your scheduled effects. This ensures that side effects, which can be slow, never make your UI feel sluggish. Before running the new effect, it runs the cleanup from the previous one.

Conclusion

You've now unpacked the core mechanics of useEffect. It's not just a function that runs on render; it's a sophisticated system for synchronizing your component with the outside world.

Key Takeaways:

• Dependency Array: Its purpose is to control when your effect re-runs. It works by comparing dependencies using Object.is(), which means you must be mindful of reference equality for objects, arrays, and functions.
• Cleanup Function: Its purpose is to prevent side effects from "leaking" outside their intended lifecycle. It runs on component unmount and before the next effect execution.
• Primary Roles of Cleanup: The two most critical roles are preventing memory leaks (from subscriptions, timers, event listeners) and avoiding race conditions in asynchronous operations.
• Execution Timing: Effects and their cleanups are scheduled during the render phase but run asynchronously after React has committed changes to the DOM and the browser has painted, ensuring a responsive UI.

What's Next?

We've seen how creating new object or function references on every render can cause useEffect to run unintentionally. This begs the question: how can we preserve the same reference across renders for performance-critical operations?

In our next lesson, we will explore useMemo and useCallback. These hooks are designed specifically for this purpose: memoizing values and functions to prevent unnecessary re-renders and effect executions. This will complete your foundational toolkit for optimizing React components.