Re: [whatwg/dom] Expose an `aborted` promise on AbortSignal? (#946)

> @Jamesernator I'm not sure I follow. Are you saying your proposal should change or should stay as it is?

That it should change. Your `abortableTask` would work fine. I was thinking `Promise.race` would keep references to the promises (so if one was eternal it wouldn't be collected), but no that's not the case it's the other way around (the raced promise holds a reference to `Promise.race`'s resolve/reject method).

It'd be quite cool as a method of abort signal so that we could just do:

```js
function animationFrame(abortSignal) {
  return abortSignal.task((setOnAbort) => {
    return new Promise((resolve) => {
      const frameRequest = requestAnimationFrame(time => resolve(time));
      setOnAbort(() => cancelAnimationFrame(frameRequest));
    });
  });
}
```

I don't think it quite meets the OP use case. But I've generally found the `doAbortable` pattern to be sufficient for most cases. I can see a promise being useful on occasion, but I feel like asynchronous cleanup (via `.then(...)`) might introduce a hazard where people call `controller.abort()` and expect certain work to not continue, but work is still enqueued on the microtask queue and runs before the `.then(...)` handler.

-- 
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/946#issuecomment-774937867