> 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. This feels very similar to the arguments people made in the past to stick with legacy callback-based APIs, and resist moving to promises. I'm hoping to put together something similar to the [promises guide](https://www.w3.org/2001/tag/doc/promises-guide) soon, which plays a similar role in helping make it clear that the ecosystem has transitioned and that new specs should follow. I will note that APIs that were designed during the transition period, and chose to stick with callbacks, eventually had to undergo a painful migration to promises. (Notably WebCrypto and WebRTC.) > @domenic do you have a reference for FetchController? I couldn’t find a proposal. https://github.com/whatwg/fetch/issues/447#issuecomment-281731850 is what I could find, although it doesn't seem super up-to-date, e.g. I would expect there to be inheritance of FetchController from AbortController and FetchSignal from AbortSignal, instead of duplication of the relevant members. -- 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-534815612
Received on Wednesday, 25 September 2019 01:49:45 UTC