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

Definition of AbortController, for newbs like me who don't know: https://dom.spec.whatwg.org/#interface-abortcontroller

A few questions:
1. Does the Promise return of first() mean that event dispatch to a client that registered with first() takes an extra trip around the event loop? If so, wouldn't that hurt performance? What is the benefit?
2. Do the subscription methods that take an Observable potentially have the same issue as 1?
3. Could someone provide an explanation of the semantics of takeUntil()? It is not clear to me from the name and example.
4. Does the map/filter stuff really provide meaningful syntactic sugar? For example, take this case:

```
element.on("click").
    filter(e => e.target.matches(".foo")).
    map(e => ({x: e.clientX, y: e.clientY })).
    subscribe(handleClickAtPoint);

```

What if on() was just a very short synonym for addEventListener instead? Then you could write:

```
element.on("click", 
           e => if (e.target.matches(".foo")) {
                handleClickAtPoint({x: e.clientX, y: e.clientY}) 
           } )
```

This seems equally clear, and likely would be more efficient, since only one JS function is called per dispatch instead of 3. What's the win?

It's not totally clear to me why the first version is better. If anything, a bigger win to ergonomics would be adding Point Event.clientPoint.


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