Re: [w3ctag/design-reviews] TAG Review Request: queueMicrotask (#294)

> @dbaron Cancellation seems reasonable to me. @domenic any opinions on that?

Fergal and I discussed this offline. We were initially agnostic, but came around eventually to thinking that cancelation isn't desirable, at least for now. The main reasons are:

- It isn't part of the base primitive in existing spec infrastructure, and probably not in implementations either. Promise and mutation observer microtasks are never canceled. As this API is in the spirit of exposing primitives, we shouldn't add on top of it.
- It isn't nearly as necessary for queueMicrotask as it is for the other scheduling APIs, because microtasks are basically-synchronous, so the intervening time you'd have to cancel is small. In other words, it's much harder to get new information that would cause you to cancel during the rest of your synchronous turn, than it is when multiple event loop turns could happen. For example it would be impossible for a user to click a "Cancel" button that triggers an event handler to cancel the microtask; the event handler would always fire after the microtask already completed.
- If users really want this, they can build it themselves, by doing `queueMicrotask(() => { if (canceled) { return; } ... })`. Unlike similar code with `setTimeout()`, `requestAnimationFrame()`, et al., asking the browser to hold on to a now-redundant closure is not a big deal, because it's such a short time period.
- There's no precedent in user-space libraries that attempt to give microtask semantics, even though such libraries could emulate cancelation by doing `if (canceled) { ... }` wrapping.

-- 
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/294#issuecomment-409725003