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

It's interesting so many people are focusing on first(). I guess that makes sense given that it was a prominent example. But it isn't really as big a part of the proposal as you might assume.

Rather, I think of it in terms of the observable <-> array analogy. Arrays have a few combinators that produce other arrays, such as map, filter, flatMap, and slice. They also have other combinators that produce scalar values, such as `a[i]`, every, find, includes, and reduce. `first()` is just a particular case of the `a[i]` combinator, translated to observables. Indeed, it's really a special case of the `observable.at(i)` combinator, which is omitted here because in practice it's not very useful apart from `observable.at(0)`, for the common cases where you end up with only a single event (or other object) in the observable. So instead what's proposed is `observable.first()` directly.

It's true that once you convert your observables to a scalar values, you enqueue a microtask. But by that time you're usually "done", and not processing these things as events, but instead as scalar values converted from events. This is more obvious with cases like

```js
// Find the maximum Y coordinate while the mouse is held down.
const maxY = await element.on("mousemove")
                          .takeUntil(element.on("mouseup"))
                          .map(e => e.clientY)
                          .reduce((y, soFar) => Math.max(y, soFar), 0);
```

So I at least am not too worried about `first()`; it just is part of this general family. I think most people will understand that once you await something, you're treating it more as something that happened in the past, not something that is ongoing and you have a chance to cancel or stop propagation of.

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