Re: [whatwg/dom] Consider adding a timeout parameter to the AbortController constructor (Issue #1110)

I think this proposal is a bad idea and would be poor API design. The constructor of an object should vend its fundamental capabilities. It should not provide a syntactic shortcut for saving an extra line of setup, by connecting the constructed object to a totally different part of the web platform. (In this case, the event loop and timer subsystem.)

Furthermore, `AbortController`s created in this way are harder to reason about. They have a hidden, implicit caller of `abort()`, which you cannot see. You have to know that whoever created it, hid such a call from you in the constructor. You can no longer scan for all `abort()` calls to find all ways the controller might be aborted.

I don't think we have evidence that the use case in question (roughly, creating an `AbortController` that is controlled by both a timeout and other callers) is very popular. And if we did, I don't think we have evidence that being explicit, using `setTimeout()`, is a huge burden. (Note that `AbortSignal.any()` is not actually needed, you can do `const controller = new AbortController(); setTimeout(() => controller.abort(), 5000);` and then pass `controller onward.)

I hope we keep the `AbortController` constructor simple and focused on its core capabilities. Any syntactic sugar should continue to be done at the `AbortSignal` level, like we've done with `AbortSignal.timeout()` and like we're proposing to do with `AbortSignal.any()`. Static factory methods there both avoid messing up the API construct of the controller's constructor, and can pull their own weight by saving more than a single extra line (since they abstract away the entire `AbortController` object).

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

Message ID: <whatwg/dom/issues/1110/1242811392@github.com>