Re: [whatwg/dom] Specify that AbortController#abort() be bound to AbortController instance (#981)

> flawed construct for it's intended purpose

The API seems to cover more than one use case and control flow pattern. Separation of the controller and signal allows sharing the signal with code that supports reacting to the abort event / observing the aborted status even when that code shouldn't also have control over whether or when the signal aborts. In cases where the consumer of the signal should be able to control aborting, well - that's when you pass the _controller_ instead of the signal alone.

We use AbortController/AbortSignal a ton but it's very rare that we pass controllers around. I only turned up one instance of sharing a controller just now out of hundreds of usages of AC/AS. So while we likely have different most-common-needs, it does not seem accurate to me to say the current model is flawed: it meets our needs and your suggested change would not.

I agree that utilities for common AC/AS usage patterns would be fantastic though - to me it seems that's the underlying issue, maybe? AC/AS provide the control flow primitives, but the API surface isn't specifically optimized for any of them in particular, so e.g. in your case it ends up seeming overly complex, while in our case it tends to demand a lot of explicit wiring-up. At this point we have a pretty extensive set of helper functions for working with signals (e.g. `await race(signal, promise)` potentially rejects w/ AbortError DOMException) and I suspect many of them are things people end up reinventing over and over right now.

-- 
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/981#issuecomment-844568759