Re: [w3ctag/design-reviews] Scheduling APIs (#338)

@kenchris @domenic 

> Yes, I strongly recommend replacing the `.cancel()` with an `AbortController`-based design. In fact I think the design could be changed to just return promises, moving other manipulation methods to a subclass of the `AbortController` (similar to our plans for `FetchController`). This would allow eliminating the `Task` class altogether, which IMO would be a big simplification for the platform, as right now `Task` occupies much of the same design space as `Promise`.

Thanks for the suggestion. My fear is that by replacing useful, common scheduling abstractions like `Task` and `TaskQueue` with a strict controller/signal/promise design, that the ergonomics will suffer and we’ll make the API for a complex area even more complex.

At the same time, being able to combine other signals with this API is powerful and we’re exploring alternate API shapes that support/use signals/controllers, and I’ve filed an [issue](https://github.com/WICG/main-thread-scheduling/issues/5) in the explainer repo to track this. One powerful use case outside of abort is changing priority, if we support that for other async APIs like `fetch()`.

@domenic do you have a reference for `FetchController`? I couldn’t find a proposal.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/338#issuecomment-534778379