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

> Is there a way to avoid the indeterminate timing?

All the ways I think of are pretty deep-cutting, because this is a preexisting problem. For example:

```js
form.addEventListener("submit", e => {
  console.log(1);
  Promise.resolve().then(() => console.log(2));
});
```

In this case if the user clicks submit, this will always log 1, then 2, with no JS code running in between them (besides potentially other enqueued microtasks). Whereas if you do

```js
form.submit();
console.log(3);
```

then this will log 1, then 3, then 2.

We could "fix" this case, and thus also the observable case, by e.g. inserting a microtask checkpoint after all event firing, even if the stack is not empty. That breaks a lot of assumptions about promise-using code though, that promise callbacks only run with an empty stack.

My and @jhusain's take is instead to say that this existing feature of the platform is reasonable already, or at least something we'd want to solve separately. Instead, if we really believe that `first()` is a footgun, we can provide mitigations like allowing `el.on("submit").do(e => e.preventDefault()).first().then(doMoreStuff)` or (new proposal) `el.on("submit").first(e => e.preventDefault()).then(doMoreStuff)`. In both cases the idea is that when converting to a scalar you get a chance to intercede and do something sync before going into async-promise-land.

-- 
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-351779661