In React, how do you wire an AbortController into a useEffect that calls fetch, and why must the controller be created inside the effect body rather than held in a ref?

## The wiring, in full ```js useEffect(() => { const controller = new AbortController(); fetch(url, { signal: controller.signal }) .then((res) => res.json()) .then(setData) .catch((err) => { if (err.name === 'AbortError') return; setError(err); }); return () => controller.abort(); }, [url]); ``` Three moving parts: a controller created per effect run, its `signal` handed to `fetch` through the options object, and `abort()` called from the function the effect returns. Everything else is detail. ## Why the controller belongs inside the effect body An `AbortController` is a one-shot device. Calling `abort()` flips its signal permanently — `signal.aborted` is `true` from then on and there is no reset. Anything you subsequently pass that signal to is cancelled the moment it starts, because a request handed an already-aborted signal does not run at all. That is why the controller has to be created fresh in each effect run and cannot be stashed somewhere that survives across runs: ```js // broken const controllerRef = useRef(new AbortController()); useEffect(() => { fetch(url, { signal: controllerRef.current.signal }).then(/* ... */); return () => controllerRef.current.abort(); }, [url]); ``` The first run works. Its cleanup aborts the ref's controller. The second run passes that same, now-permanently-aborted signal to `fetch`, so the request never leaves — and every run after it fails the same way. The bug presents as "data loads once and then the screen is stuck empty", which is a long way from where the mistake is. The same argument rules out module-scope controllers, which would additionally let two mounted components abort each other's requests. ## Creating it in the effect, not in render The controller also does not belong in the component body. Render runs on every re-render, so a controller created there is a new object each time while the request in flight still holds the old signal — the cleanup would abort a controller nothing is listening to. Effect body is the right home because effect body and cleanup are the two halves of one run, closing over the same `controller` binding. ## Cleanup timing is what makes this correct React calls the returned function before re-running the same effect and once at unmount. Both cases matter here. At unmount you are cancelling work whose result has nowhere to go. On a dependency change — `url` changed — you are cancelling the request for the old `url` before firing the one for the new `url`, so a component that would otherwise accumulate one in-flight request per keystroke keeps at most one alive. ## The rejection you must handle Aborting does not make the promise vanish; it rejects it. If nothing catches that rejection you get an unhandled rejection in the console every time the user navigates away mid-request, and if the catch is unconditional you paint a failure state for a request you deliberately cancelled. So the catch has to recognise the abort — the rejection reports itself with the name `AbortError` — and return without touching state. With `async`/`await` the shape is the same; the `await` throws and the guard goes at the top of the `catch`: ```js try { const res = await fetch(url, { signal: controller.signal }); setData(await res.json()); } catch (err) { if (err.name === 'AbortError') return; setError(err); } ``` Note that the abort also cuts off body reading, so `res.json()` can reject with the same error — one guard covers both. ## What abort does and does not buy you What it does: stops the browser waiting on the response, closes the connection so the browser's per-host connection budget is freed for requests the user is actually waiting on, stops the response body from being downloaded and parsed, and rejects the promise so your code stops. What it does not: undo anything. The request may already have reached the server and been fully processed — abort is a client-side cancellation, not a rollback. That is why aborting a `GET` is routine and aborting a `POST` that creates something is not a way to "cancel the write"; if a mutation needs to be reversible, that is a server-side concern, not a signal. ## Passing the signal onward When the effect calls a wrapper of your own — `loadUser(id, { signal })` — the signal has to be threaded all the way down to the `fetch` at the bottom. A wrapper that accepts a signal and quietly ignores it is worse than one that never accepted it, because the call site looks cancellable and is not, and the effect's cleanup becomes a lie.