Optimizing `useEffect` with Dependency Arrays

The Problem: Unnecessary Reruns

In the last lesson, you learned that if you omit the dependency array entirely, the effect runs after every single render. Let's see why this can be a problem.

Imagine a component with two separate state variables: one to track a resource id (e.g., from a URL or dropdown) and another to toggle a dark mode theme.

import { useState, useEffect } from 'react';

function ResourceViewer() {
  const [resourceId, setResourceId] = useState(1);
  const [isDarkMode, setIsDarkMode] = useState(false);

  useEffect(() => {
    // This effect fetches data based on resourceId
    console.log(`Fetching data for resource ${resourceId}...`);
    // fetch(`https://api.example.com/items/${resourceId}`);
  }); // <-- No dependency array!

  return (
    <div style={{ background: isDarkMode ? '#333' : '#FFF', color: isDarkMode ? '#FFF' : '#333' }}>
      <button onClick={() => setResourceId(id => id + 1)}>
        Next Resource
      </button>
      <button onClick={() => setIsDarkMode(dark => !dark)}>
        Toggle Theme
      </button>
      <p>Viewing resource: {resourceId}</p>
    </div>
  );
}

If you run this code, you'll see "Fetching data..." in the console not only when you click "Next Resource," but also when you click "Toggle Theme." The data fetching effect is running even when the resourceId hasn't changed. This is inefficient and can lead to unnecessary API calls, wasting both client resources and server bandwidth.

The Solution: The Dependency Array Watchlist

To fix this, we provide a "watchlist" of dependencies as the second argument to useEffect. This array tells React: "Only re-run this effect if one of these values has changed since the last render."

By adding resourceId to our watchlist, we tell React to ignore changes to any other state or prop, like isDarkMode.

useEffect(() => {
  console.log(`Fetching data for resource ${resourceId}...`);
  // fetch(`https://api.example.com/items/${resourceId}`);
}, [resourceId]); // <-- Now it only watches resourceId

With this change, toggling the theme will no longer trigger the console log. The effect is now correctly synchronized only with the data it depends on.

This is the core principle for building interactive components. For example, if you have a search input, you can make an effect that re-fetches data every time the search query changes.

The Rules of Hooks: Dependencies are Not Optional

You might be tempted to think you can choose what to put in the dependency array. However, the React team is very clear: Every reactive value from the component scope (props, state, functions) that is used inside your effect must be included in the dependency array.

This isn't just a style guide; it's a rule to prevent bugs. Your code editor's linter (if configured correctly) will warn you about this with the react-hooks/exhaustive-deps rule. Do not ignore this warning!

So, why is this rule so strict? Let's explore the two major bugs it helps you avoid.

Pitfall 1: Stale Data (Missing Dependencies)

When an effect runs, it creates a "closure" over the variables it uses. If you don't include a variable in the dependency array, the effect will "remember" the value of that variable from the first time it ran and will not see its updated value on subsequent re-renders. This is called a stale closure.

As you saw, failing to list dependencies can lead to your effect working with outdated information, causing subtle and hard-to-debug issues. Always trust the linter.

Pitfall 2: Infinite Loops

The second common pitfall occurs when an effect's logic causes a dependency to change, which then re-runs the effect, creating an infinite loop.

Here's a classic example:

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

  useEffect(() => {
    const intervalId = setInterval(() => {
      // This effect sets state, causing a re-render.
      setCount(count + 1); 
    }, 1000);

    return () => clearInterval(intervalId);
  }, [count]); // 🚩 ...but it also depends on the state it sets!

  return <h1>{count}</h1>;
}

The Loop:

1. Component renders, count is 0.
2. useEffect runs, reads count as 0, sets up an interval.
3. After 1 second, setCount(0 + 1) is called.
4. count is now 1, triggering a re-render.
5. Since count changed, useEffect runs again. The old interval is cleared, and a new interval is created.
6. This cycle repeats forever, resetting the interval every second.

The Fix: Functional State Updates

To break this loop, you can use the functional update form of a state setter. Instead of passing the new value directly, you pass a function that receives the previous state and returns the new one.

useEffect(() => {
  const intervalId = setInterval(() => {
    // This updater function gets the latest count from React
    setCount(c => c + 1); 
  }, 1000);

  return () => clearInterval(intervalId);
}, []); // ✅ Now the effect no longer depends on `count`

Since we no longer need to read the count variable inside the effect, we can safely remove it from the dependency array. The effect now runs only once, but the setCount updater always has access to the most recent state.

Pitfall 3: Unstable Dependencies (Objects & Functions)

A dependency array works by comparing values using Object.is (similar to ===). For primitive values like numbers and strings, this works as expected. But for objects and functions, it compares their references in memory.

Since objects and functions defined inside a component are recreated on every render, their references change every time, even if their contents are identical.

function MyComponent({ userId }) {
  // 🚩 This options object is a new object on every render
  const options = {
    id: userId,
    active: true
  };

  useEffect(() => {
    fetchData(options);
  }, [options]); // 🚩 This will run on EVERY render, because options is always "new"
  
  // ...
}

This will cause your effect to run on every render, defeating the purpose of the dependency array.

Common Fixes:

1. Move them inside: If an object or function is only used by the effect, define it inside the effect.
2. Destructure primitives: Instead of depending on an entire object, depend on the primitive values within it.

// Fix 1: Move inside
useEffect(() => {
  const options = { id: userId, active: true }; // Now created inside
  fetchData(options);
}, [userId]); // Now only depends on the primitive `userId`

// Fix 2: Destructure (if options were a prop)
// useEffect(() => { ... }, [options.id, options.active]);

For more complex cases involving functions, you might eventually use hooks like useCallback and useMemo, but the two fixes above solve the vast majority of cases.

import { useState, useEffect } from 'react';

// Assume this component is used like <UserDetails userId={2} />
function UserDetails({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    setLoading(true);
    fetch(`https://jsonplaceholder.typicode.com/users/1`) // <-- Hardcoded!
      .then(res => res.json())
      .then(data => {
        setUser(data);
        setLoading(false);
      });
  }, []); // <-- This dependency array is also incorrect for a dynamic ID

  if (loading) return <p>Loading...</p>;

  return (
    <div>
      <h1>{user?.name}</h1>
      <p>Email: {user?.email}</p>
      <p>Phone: {user?.phone}</p>
    </div>
  );
}

import { useState, useEffect } from 'react';

function UserDetails({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    setLoading(true);
    // 1. Use the userId prop in the fetch URL
    fetch(`https://jsonplaceholder.typicode.com/users/${userId}`)
      .then(res => res.json())
      .then(data => {
        setUser(data);
        setLoading(false);
      });
  // 2. Add userId to the dependency array
  }, [userId]);

  if (loading) return <p>Loading...</p>;

  return (
    <div>
      <h1>{user?.name}</h1>
      <p>Email: {user?.email}</p>
      <p>Phone: {user?.phone}</p>
    </div>
  );
}

Conclusion

You've now unlocked the full power of useEffect! By carefully managing the dependency array, you can create efficient and bug-free components that synchronize with external systems in response to state and prop changes.

Key Takeaways:

• The dependency array is a "watchlist" that tells useEffect when to re-run.
• The Rule: Every reactive value (props, state) used inside an effect must be in the dependency array. Trust your linter!
• Stale Data: Forgetting a dependency causes the effect to use old values.
• Infinite Loops: Occur when an effect updates a state variable that it depends on. Fix this with the functional update form of setState (e.g., setCount(c => c + 1)).
• Unstable Dependencies: Objects and functions created during render will have new references every time, causing effects to run too often. Move them inside the effect or depend on their primitive values instead.

In our next lesson, we'll put this knowledge to use as we learn to render dynamic lists of data and apply conditional rendering—skills you'll need for the upcoming mid-course project