Infinite Re-Render Loop From setState in useEffect? Stop It

The browser tab freezes. The console shows the same log thousands of times. React finally gives up and warns about the maximum update depth being exceeded. You have hit the classic React trap: an infinite re-render loop caused by calling setState inside useEffect.

This loop follows a predictable pattern, and once you see the pattern, the fixes become straightforward. This guide explains the cycle step by step, shows the most common versions of the bug, and gives you reliable ways to stop it without weakening your component.

Quick Answer

An infinite re-render loop happens when a useEffect updates state, that state change re-renders the component, and the effect runs again because one of its dependencies changed identity or value. Stop it by giving the effect correct dependencies, avoiding new object or array references on every render, using the functional form of setState, and removing state updates that do not belong in an effect at all.

How the Loop Works

Follow one full cycle and the bug explains itself:

1. The component renders and React runs the effect after the render.
2. The effect calls a state setter, such as setCount or setUser.
3. React stores the new state and schedules another render.
4. The component renders again. Because a dependency of the effect changed, React runs the effect again.
5. The effect calls the setter again, and the cycle repeats forever.

Nothing here is broken in React. Each step is React doing exactly what the code asks. The problem is circular logic: the effect both depends on state and replaces that state on every run.

The most obvious version is an effect with no dependency array that sets state. Without the array, the effect runs after every render, so every state update guarantees another effect run. Adding the dependency array helps, but as the next sections show, it is not always enough.

The Most Common Causes

Cause 1: No Dependency Array

This code loops from the first render:

useEffect(() => { setData(loadData()); });

The missing second argument means run after every render. If the effect only needs to run once on mount, pass an empty array: useEffect(() => { ... }, []);. Be honest about what the effect uses, though, because an empty array with hidden dependencies creates stale data bugs instead.

Cause 2: An Object or Array in the Dependencies

Objects and arrays are compared by reference, not by content. If you create the object during render, it is a new reference every time:

const options = { sortBy: "name" }; useEffect(() => { setResults(fetchResults(options)); }, [options]);

Every render creates a fresh options object, React sees a changed dependency, the effect runs, setState triggers a render, and a fresh object appears again. The contents never changed, but the reference always does.

Fixes for this cause, in order of preference:

• Move the object inside the effect if nothing else needs it.
• Depend on the primitive values inside the object, such as options.sortBy, instead of the whole object.
• Wrap the object in useMemo so its reference stays stable until its real inputs change.
• Define constant objects outside the component, where they are created once.

Cause 3: Setting the Same State the Effect Depends On

An effect that depends on count and also calls setCount based on count will re-trigger itself. Sometimes this is genuinely needed once, for example normalising a value, but the update must converge. If the new value equals the old value for primitive state, React can bail out. For objects, a freshly built object never equals the old one, so the loop never settles.

Guard the update: only call the setter when the value actually changes, and compare meaningful fields rather than object identity.

Cause 4: Updating State During Render

A close cousin of this bug is calling a setter directly in the component body instead of in an effect or handler. React allows a narrow pattern of adjusting state during render for derived values, but unconditional updates in the body re-render endlessly. Keep render pure: compute what you display from props and state, and move changes into handlers or effects.

Step-by-Step Fixes That Work

Step 1: Use the Functional Update Form

When the new state depends on the old state, pass a function to the setter: setCount(prev => prev + 1);. The state variable then no longer needs to be a dependency of the effect, which often breaks the cycle and is the pattern React recommends. This is explained clearly in the React documentation on useEffect dependencies and state updates.

Step 2: Calculate Derived Values During Render

A surprising number of looping effects exist only to copy or transform state: filtering a list, doubling a number, combining first and last names. None of that needs an effect or separate state. Compute it during render:

const fullName = firstName + " " + lastName;

Derived values recalculate automatically when their inputs change, can never go out of sync, and remove the effect, the extra state, and the loop in one move.

Step 3: Move Event Responses Into Event Handlers

If the effect reacts to something a user did, such as submitting a form or clicking a button, the work belongs in that handler. Effects should synchronise with external systems, not respond to events. Moving the logic removes the dependency tangle entirely.

Step 4: Stabilise Callbacks and Fetched Data

Functions defined in the component are also new references each render. If a function is an effect dependency, wrap it in useCallback with honest dependencies, or move it inside the effect. For fetching, protect the effect with a cleanup flag or AbortController so stale responses cannot set state after cleanup. Understanding the development behaviour in our guide on why useEffect runs twice in React 18 development mode also helps you separate a harmless double run from a true endless loop.

Step 5: Add a Temporary Guard While Debugging

If the tab is freezing, add a quick condition so the effect only updates when data really changed, reload, and then read the logs calmly. A guard is a debugging aid and sometimes the correct final fix, but if you need it because references keep changing, fix the references rather than hiding behind the condition forever.

Common Mistakes and Useful Tips

• Silencing the linter. Disabling the exhaustive-deps rule to stop warnings usually converts a visible loop into an invisible stale-data bug. Fix the dependency instead.
• Storing everything in state. If a value can be calculated from props or other state, storing it separately invites loops and mismatches.
• Fetching without cleanup in a list page. Rapid filter changes fire many requests; without an ignore flag or abort, late responses overwrite newer results.
• Blaming StrictMode for a real loop. StrictMode double-runs effects in development and then stops. A loop that never stops, or that appears in production, is your dependency logic, not StrictMode.
• Using refs to hide dependencies as a first resort. Refs have valid uses for values that should not trigger renders, but reaching for them to dodge every dependency warning makes effects unpredictable.

A practical debugging tip is to log inside both the render and the effect with distinct messages. The repeating sequence shows you exactly which step re-triggers the next, and which dependency changed, far faster than guessing.

Conclusion

An infinite re-render loop from setState in useEffect is always the same circle: effect updates state, state re-renders, dependencies change, effect runs again. Break the circle at its weakest point. Give the effect accurate dependencies, keep object and function references stable, use functional updates, calculate derived values during render, and move event logic into handlers. With those habits, effects become calm, predictable synchronisation instead of the most common source of frozen tabs in React apps.

Frequently Asked Questions

What does maximum update depth exceeded mean?

It is React’s safety limit. React detected nested updates repeating beyond a threshold, usually from a setter called during render or from an effect loop like the one in this guide, and stopped to protect the browser from freezing completely.

Is an empty dependency array always the solution?

No. An empty array means run once on mount. If the effect reads props or state that change later, the effect will use stale values. List every value the effect reads, and restructure the code if that list causes a loop.

Why does my loop happen only sometimes?

Conditional data can hide the loop until a particular value appears. For example, the loop may start only when a fetch returns an object, creating new references, or when a filter produces an array the effect depends on and also replaces.

Can useMemo and useCallback cause loops too?

Yes, if their dependencies include unstable references, they recalculate every render and can feed the same instability into effects that depend on them. Stabilise the root values first; memoisation built on shifting inputs does not help.

How do I tell a loop apart from StrictMode double effects?

StrictMode runs an effect, cleans it up, and runs it once more, then stops. A loop keeps going indefinitely and often triggers the maximum update depth warning. Testing a production build also helps, since StrictMode checks are development-only.