React 18 removed the 'Can't perform a React state update on an unmounted component' warning. Does that mean effects that fetch no longer need cancellation and cleanup?

## What the warning said and why it went Before React 18, updating state on a component that had already unmounted logged: *Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application.* React 18 removed it, and the reasoning is the interesting part. The message was self-contradicting. It correctly said the update is a no-op, then asserted a memory leak on that basis — but a no-op update leaks nothing. React drops it and moves on. The genuine leak, when there is one, is whatever is still running and still holding references: the interval, the subscription, the listener. The state setter is merely the most visible symptom of that, and often it is not present at all. Worse, the warning taught a bad fix. To silence it, thousands of codebases added a flag: ```js useEffect(() => { let mounted = true; load().then((data) => { if (mounted) setData(data); }); return () => { mounted = false; }; }, []); ``` That stops the message and stops nothing else. The request still runs to completion, the response body is still downloaded and parsed, the server still did the work. The flag added a line of ceremony, retained one more closure, and left the actual waste untouched — while making the code look as though cleanup had been handled. ## What is true after the removal Calling a state setter on an unmounted component in React 18 and later is silent and inert. No warning, no error, no render. That fact changes exactly one thing: it removes a reason to write cleanup that was never a good reason in the first place. Everything else stands, and it splits into two distinct arguments that candidates routinely merge. **Argument one — real leaks.** Anything an effect starts that keeps running must be stopped, because nothing else will stop it: `setInterval`, `setTimeout`, `requestAnimationFrame`, event listeners, `IntersectionObserver` and `ResizeObserver`, WebSocket connections, subscriptions to any external system. These accumulate across mounts, keep firing on screens the user has left, and retain everything their callbacks close over. This is a correctness and memory problem, and it never had anything to do with the warning. **Argument two — wasted work.** An in-flight `fetch` is not a leak: it settles, its promise is collected, and nothing is retained. Cancelling it is an efficiency and resource argument, and the specifics are what an interviewer wants to hear: - A browser allows only a handful of concurrent connections per host. A component that fires one request per keystroke and cancels none can saturate that budget with obsolete requests, so the request the user is actually waiting on queues behind answers nobody wants. - Aborting stops the response body from being downloaded and parsed — on a slow connection that is the expensive part, and on a metered mobile connection the user pays for it. - Downstream, the server and its database do work whose result is discarded. At one user that is nothing; across a large user base of fast typers it is a measurable share of traffic. - On a page that mounts and unmounts frequently, cancelling keeps the number of in-flight requests bounded by what is on screen rather than by how much the user has clicked. ## How to answer the question in an interview Separate the three claims explicitly. First: an update after unmount is inert, so that is not the reason. Second: whatever the effect started that is still running is a real leak, and only the cleanup function stops it. Third: cancellation of requests is about not paying for answers nobody will read, and about not crowding out requests that matter. The most common weak answer collapses all three into "you have to clean up or you get a memory leak", which is right about the conclusion for the wrong reason, and cannot explain why React deleted the warning. ## What this does not license Removing the warning also removed a diagnostic. It used to be a crude smoke alarm — noisy and often wrong about the cause, but it did fire. Nothing replaced it, so effects that skip cleanup now fail silently: no console output, just growing request volume and timers that outlive their screens. The practical consequence is that this class of bug has to be caught by review and by monitoring rather than by the console, which is a good reason to keep cleanup as a mechanical habit rather than something you add when something complains.