Re: [whatwg/dom] Improving ergonomics of events with Observable (#544)

I'm worried about the cases where people will use this for purposes other than convert to a scalar.  `form.on("submit").first().then(myFunc)` looks nicer than `form.addEventListener("submit", myFunc, {once: true})`. It's a lot more appealing to write than sticking `Promise.resolve().then()` into your event handler function. But it's not obvious from the syntax that it may create weird timing issues. I totally believe that thoughtful web developers can use this well. But if it becomes the cool new best way to handle events all he time, then its use will not be limited to thoughtful web developers.

As far as where to fix this, if we cared to: there are other options than altering the timing of microtask dispatch in general. For example, one could instead imagine creating a new kind of "eager Promise" that is usable with async/await and other Promisey things, but which calls the then() callback synchronously instesad of at microtask time when resolved. Using that instead of a regular Promise would remove the timing hazard without messing with all uses of microtasks. It's not clear to me that the deferral to microtask time is doing any work here. Alternately, one could imagine that this form of Promise is still always async, but gets extra opportunities to run at times we wouldn't fire other microtasks when other JS is on the stack.

(Apologies if I have butchered Promise-related terminology or concepts here). 

-- 
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/544#issuecomment-351788994