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

As an implementer, I'm focusing on things that could be hard to implement, that could cause performance issues, or that may cause weird behavior inconsistencies that are not obvious. The Promise-returning methods seem to be the most likely to cause strangeness because of the tricky timing rules for when Promises fire. The challenge with Promises in the context of event propagation is that they are sometimes "things that happened in the past" but other times they are happening in the middle of event dispatch just where you expect. 

Because the syntax is concise, I expect people will want to use this even if they don't intend to do sequence operations on the event stream.

For example, an author might reasonably expect `form.on("submit").first(e => /* do stuff that alters form fields before submission */)` to work, and it will sometimes work, but other times it won't. And on the flip side, it's also not safe to assume in that `first()` callback that form has already been submitted so it's safe to make post-submission changes. Either could be true. It depends on whether the form was submitted from JavaScript or directly by a user action.

Is there a way to avoid the indeterminate timing?


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