Prevent React Unmounted Component State Update Errors

By Krapton Engineering · Reviewed by a senior engineer · Last updated Sep 5, 2026

You’ve seen the warning: Can't perform a React state update on an unmounted component. It’s a ubiquitous headache for React developers, often appearing when users navigate away while an asynchronous operation, like an API call, is still in flight. This isn't just a noisy console message; it signals potential memory leaks, race conditions, and an unstable user experience that can degrade application performance and user trust.

TL;DR: To prevent 'Can't perform a React state update on an unmounted component' errors, always implement proper cleanup for asynchronous operations within your useEffect hooks. Use an isMounted ref pattern for simple cases or, for network requests, leverage the AbortController API to cancel fetches when the component unmounts, ensuring state updates only occur on active components.

Key takeaways

• The 'Can't perform a React state update on an unmounted component' warning indicates an attempt to update state after a component has been removed from the DOM.
• Ignoring these warnings can lead to memory leaks, unexpected UI behavior, and race conditions in complex applications.
• The useEffect hook's cleanup function is crucial for managing asynchronous side effects and preventing these errors.
• Two primary patterns for robust cleanup are the isMounted ref pattern and the AbortController API for network requests.
• For complex data fetching and caching, consider dedicated libraries like React Query, which abstract away much of this boilerplate.

The Problem: State Updates on Unmounted Components

Imagine a user clicks a button that triggers a data fetch, then quickly navigates to another page before the API request completes. When the API eventually responds, your component—now unmounted—still tries to update its state. React detects this and throws the infamous warning. While not always a hard crash, these warnings are symptomatic of deeper issues: resource waste, unpredictable UI, and a general lack of robustness in your application's asynchronous logic.

Why does this happen? React components have a lifecycle. When a component mounts, it's added to the DOM. When it unmounts, it's removed. Asynchronous operations, by definition, don't respect this synchronous lifecycle. They run independently, and if their callbacks attempt to interact with a component that no longer exists, you have a problem. In a recent client engagement involving a complex data dashboard, we observed a subtle memory leak and intermittent UI glitches that traced back to unhandled state updates on components that were quickly mounted and unmounted during rapid user interaction.

The Naive Approach and Its Flaws

A common, yet flawed, approach involves fetching data and updating state directly within a useEffect hook without any cleanup mechanism. This works fine for simple cases where the component is guaranteed to stay mounted, but it breaks down under real-world user navigation patterns.

import React, { useState, useEffect } from 'react';

function NaiveDataFetcher() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      try {
        const response = await fetch('https://api.example.com/items');
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }
        const result = await response.json();
        setData(result);
      } catch (err) {
        setError(err);
      } finally {
        setLoading(false);
      }
    };
    fetchData();
  }, []); // No cleanup, no dependencies

  if (loading) return <p>Loading data...</p>;
  if (error) return <p>Error: {error.message}</p>;

  return (<div>{/* Display data */}</div>);
}

In this naive example, if NaiveDataFetcher unmounts before fetchData completes, setData, setLoading, or setError will be called on an unmounted component, triggering the warning. On a production rollout we shipped for a high-traffic e-commerce search page, failing to implement proper cancellation for search suggestions led to a race condition where stale suggestions from previous searches would briefly flash before the correct ones, leading to a jarring user experience and increased bounce rates.

Production-Grade Solution 1: `useEffect` Cleanup with `isMounted` Flag

The core principle is to prevent state updates if the component is no longer mounted. A straightforward way to achieve this is by using a ref to track the component's mounted status and checking it before any state update. This pattern is particularly useful for non-network async operations like setTimeout or custom promise-based operations where AbortController might not be directly applicable.

import React, { useState, useEffect, useRef } from 'react';

function SafeDataFetcherMountedFlag() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);
  const isMounted = useRef(false);

  useEffect(() => {
    isMounted.current = true; // Component is mounted

    const fetchData = async () => {
      try {
        const response = await fetch('https://api.example.com/items');
        if (!response.ok) throw new Error(`HTTP error! status: ${response.status}`);
        const result = await response.json();
        if (isMounted.current) { // Only update if still mounted
          setData(result);
        }
      } catch (err) {
        if (isMounted.current) { // Only update if still mounted
          setError(err);
        }
      } finally {
        if (isMounted.current) { // Only update if still mounted
          setLoading(false);
        }
      }
    };
    fetchData();

    return () => {
      isMounted.current = false; // Component is unmounted
    };
  }, []);

  // ... (render logic as before)
}

Here, the useEffect cleanup function sets isMounted.current to false when the component unmounts. Before calling any state setter, we check isMounted.current. This pattern effectively guards against updates to an unmounted component. This approach is simple to implement and understand, making it a good default for many scenarios. However, for network requests, there's an even more robust solution.