Re: [whatwg/dom] Adding a return value to `controller.abort()` which represents abort completion (#881)

I like how in the current design of abort signals, there's only *one-way* communication from the `AbortController` to the `AbortSignal`. An `AbortSignal` can observe and get notified on the state of its parent `AbortController`, but it can in no way alter its parent's state or behavior. This allows developers to freely pass `controller.signal` around to whatever user-defined or platform-defined function (or functions), without worrying about them affecting the controller.

With the original proposal, that would break: an abort signal would now be able to change if, how and when the promise from `controller.abort()` would resolve or reject. Throw in [signals following other signals](https://dom.spec.whatwg.org/#abortsignal-follow), and you get a lot of "action at a distance".

Also, how would this interact with something like `Promise.race()`?

```js
const controller = new AbortController();
const promise = Promise.race([
  fetch("/fast", { signal: controller.signal }),
  fetch("/slow", { signal: controller.signal })
]);
// after "/fast" has been fetched:
const abortPromise = await controller.abort();
// `promise` resolves with result from "/fast"
// `abortPromise` rejects with an AbortError from "/slow"... but should it really? 😕
```

---

> ```js
> await DOMException.ignoreAborts(pipePromise);
> ```

This proposal could work. I'm already using a similar helper in my own code:
```js
function rethrowUnlessAbortError(e) {
  if (e.name !== "AbortError") {
    throw e;
  }
}

await promise.catch(rethrowUnlessAbortError);
```
Not sure about the name `ignoreAborts`, but I don't have anything better either. 🤷‍♂️

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/881#issuecomment-675141948