Re: [w3ctag/design-reviews] Observable API (Issue #902)

Hi everyone, apologies for the delay.

We discussed this in a breakout today, though we ran out of time before reaching a conclusion. The following are some personal thoughts and comments.

First, the author pain points are clear, so motivation is pretty obvious.

My main concern is the standardization venue. It seems very clear that ES will eventually need an Observable primitive and we would not want the web platform to have another conflicting primitive. Also, when it comes to pure JS language features, TC39 is the clear fit for this. The fact that `AbortSignal`/`AbortController` were *not* standardized in TC39 is unfortunate, and shows in their ergonomics — I think it's important to avoid this pattern. You mention that `Observable` does to Events what Promises did to callbacks, but one of the reasons Promises were so successful is exactly that they were specced as a language feature.

Looking at https://github.com/tc39/proposal-observable/issues/201#issuecomment-1021145957 it appears that the primary issue stems exactly from `AbortSignal` / `AbortController`. FWIW although [we generally recommend against monkey-patching](https://w3ctag.github.io/design-principles/#monkey-patching), I think it would be the lesser of two evils to have the Observable API specced by TC39, and only a `signal` parameter elsewhere, than to have the entire Observable API specced by WHATWG or another browser-centric venue.

Another concern is that it seems that this still depends on the `EventTarget` infrastructure, and basically provides a wrapper over it with better DX. But if we go through the effort of creating a completely new API, it seems like it should not come with `EventTarget` baggage, an API that was designed for the DOM and later retrofitted to other objects. E.g. as a library author, I find it unfortunate that for my objects to support events that my users can listen to I need to make them inherit from `EventTarget` (and since we don't have multiple inheritance, this precludes them inheriting from anywhere else).

Stepping even further back, we have way too many different pub/sub patterns on the Web platform and DX suffers as a result. To an author it is unclear why we have an Events system and e.g. `MutationObserver`, `ResizeObserver`, etc. I understand the reasons, no need to explain them to me, I’m just saying most authors don't and from a UI perspective, it's an implementation detail that has leaked out into the UI because the DOM Events infrastructure did not support this use case well. For a new pub/sub pattern to win them all, we really need something that would be able to support all of these cases, and be used as the underlying model for all of them (i.e. DOM Events can become a special case of Observable, same with MutationObservers etc). 

Lastly, as a more minor point than the architectural concerns above: is there 1-1 parity with what `addEventListener` can do? E.g. by looking at the API I could not figure out how to do an `once` event listener. 

Also props for a nice explainer, and especially for having code examples! I also loved that some code examples had a collapsed version with how this is done currently — wish all of them had this!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/902#issuecomment-1942576159
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/902/1942576159@github.com>