- From: Robert Kieffer <notifications@github.com>
- Date: Wed, 19 May 2021 06:41:14 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/981/844117409@github.com>
@annevk Thanks for the comments. I'm realizing that a) closing this may have been a bit premature and b) the problem isn't that _abort()_ needs to be bound to the controller instance, it's that it needs to be bound to the signal instance. Your comment has helped me realize that what is really bothering me here is that the `AbortController` is simply not necessary. It's whole raison d'etre is to bind `abort()` to `signal`. That is literally all it does. `signal` instance, `abort()` method, nothing else. As such, it is wholly redundant with the many JS language features that allow for such bindings (closures, `bind()`, `=>`, etc). Moreover it doesn't actually bind the two together, as evidenced by the fact AbortControllers can be destructured in ways that render the resulting `abort` reference useless. With that in mind, and in the spirit of your comment about offering a static, would it make sense to propose the following? 1. Provide a static method on AbortSignal for creating `[signal, abort function]` tuples. The goal being to allow incantations like ```js const {signal, abort} = AbortSignal.create() ``` 2. Deprecate or eliminate the AbortController interface altogether (due to it being a redundant and flawed construct for it's intended purpose) -- 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-844117409
Received on Wednesday, 19 May 2021 13:41:32 UTC