AbortController: Cancel In-Flight Web Requests
AbortController is a remote kill switch for web requests. You create a controller, pass its signal to a fetch call, and can then call abort() to cancel it. Use it to stop requests when a user navigates away. The footgun is forgetting this signal.
Why it exists
Before AbortController, there was no standard way to cancel a fetch request once it was sent. This led to wasted bandwidth and CPU cycles processing responses for components that were no longer visible, and created race conditions in UIs like type-ahead search. AbortController provides a unified, standard API to solve this.
The mental model
Think of AbortController as a two-part system: a detonator (controller) and a receiver (signal). You create the controller, which holds the abort() method (the detonator button). The controller also exposes a signal object. You attach this signal to one or more asynchronous operations, like a fetch call. When you call controller.abort(), it sends a signal to all listening operations, telling them to stop.
How it works
You instantiate a new controller with const controller = new AbortController(). This object has two key parts: the controller.abort() method and the controller.signal property. You pass the signal to the asynchronous operation, for example: fetch(url, { signal: controller.signal }). Later, in a different part of your code, you call controller.abort(). This causes the fetch promise to reject with a DOMException named AbortError, which you should handle in a catch block.
When to use it
Use AbortController for any fetch request that might need to be cancelled. It's crucial in modern UI frameworks (like in a React useEffect cleanup) to prevent state updates on unmounted components. It's also ideal for implementing type-ahead search bars, where you want to cancel the previous request each time the user types a new character.
When not to use it
Don't use it for critical, fire-and-forget operations that must complete, like logging an error to a service. Overusing it for very short-lived requests can add unnecessary boilerplate, but the cost is minimal. The main reason not to use it is if the async API you're calling doesn't accept an AbortSignal.
One canonical example
A user is typing in a search box. On each keystroke, you fire a new request but cancel the old one. First, create a controller variable. Inside the input's event handler, if a controller exists, call abort() on it. Then, create a new AbortController and pass its signal to the new fetch request. This ensures only the latest search completes, and you must catch the expected AbortError on the cancelled fetches.
Interview question
In which situation would using AbortController be most appropriate?
- a.Automatically re-sending a network request if the initial attempt fails due to a transient error.
- b.Handling network requests to an older API that lacks support for the AbortSignal interface.
- c.Implementing a type-ahead search where only the latest query's results are relevant.Correct
- d.Ensuring a crucial user action, like submitting a payment, completes without interruption.
Why? this is the answer
The card explicitly states AbortController is ideal for implementing type-ahead search, where previous requests are cancelled as the user types. It advises against using it for critical, fire-and-forget operations that must complete, like a payment submission, as cancellation would prevent their completion.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on web apis — each one lists the topics its interview covers.
See open roles