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

## Response to the early review comment

> 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).

I think this is what Observables attempts to do! It is true the initial integration point we're working on is [`EventTarget#when()`](https://github.com/WICG/observable/issues/39#issuecomment-2189717664)[^1] that returns an Observable over event listeners. But Observables are not, as you suggest, "dependent" on EventTarget (in that they are "limited" by EventTarget's dispatching semantics). Observables are generic; they need not vend `Event` _objects_, they can vend any kind of value. Because of this, we've thought of, and been open to, future integration with other APIs on the platform of the pub-sub sort.

Please see https://github.com/WICG/observable/issues/72 which mentions `MutationObserver`, `ResizeObserver`, and more as APIs with potential Observable-vending capabilities. I don't believe our proposal in any way precludes these kinds of APIs from converging on Observables.

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

Thanks for asking, this should be adequately described in https://github.com/WICG/observable/issues/66 and https://github.com/WICG/observable/issues/65. Basically, the parity exists in the operators and abort mechanism.

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

Thank you very much! We tried to construct it in a way to where the most visually-useful information with a high bang-for-your-buck came first.

## Response to newer review comment

> It seems (though we are not 100% certain) that this is a separate primitive than EventTarget and simply integrates with it. If that is correct, the current explainer is a little unclear on what the boundaries of each are. Does it use the same `Event` objects? Does it register event listeners behind the scenes?

It is most definitely is a separate primitive from EventTarget. Every question here should be answered in https://github.com/WICG/observable?tab=readme-ov-file#the-observable-api. It shows a custom-made Observable that has nothing to do with `EventTarget` or `Event` objects, and highlights the supported conversion from _arbitrary_ iterables/promises/async iterables ➡️ Observables. https://github.com/WICG/observable#:~:text=While%20custom%20Observables,Observer%20handler%20functions specifically mentions how event listeners are registered behind the scenes.

> How does bubbling work? Does it support bubbling to parent objects when not using the EventTarget integration?

When used with EventTargets, Observables are wrappers around event listeners. So, bubbling works the same as it would with them, since that's all controlled by DOM event dispatching infrastructure that our spec does not touch. Bubble/capture isn't a concept for Observables that are not vended by EventTargets — it's only [a concept](https://wicg.github.io/observable/#dictdef-observableeventlisteneroptions) for the EventTarget method that _produces_ Observables, to tell the underlying event infra that the event listener backing the Observable is interested in one or the other.

>  - All examples are about listening to predefined events on existing objects. How do authors create objects that can emit events? Today they need to extend EventTarget which is suboptimal. Does Observable enable a new pattern for this?

Some of this is already covered in https://github.com/WICG/observable?tab=readme-ov-file#the-observable-api, but our proposal does not provide a new way to _emit_ events from within an EventTarget. It enables a new way to _handle_ those events, by giving EventTargets the ability to vend Observables representing event listeners. Changes to EventTarget construction are outside the scope of our proposal.

>  - Do you folks have any plans to integrate with any of the other pub/sub mechanisms on the web platform or JS runtimes? E.g. all the *Observer objects, or Node’s Event emitter?

This was mentioned above, but yes just for completeness, see https://github.com/WICG/observable/issues/72. I think lots of APIs have a potential future vending Observable objects.

> While the code examples are certainly succinct, we had trouble figuring out how many of them worked and extrapolate how to write code about use cases not listed in the explainer. We were especially unclear on the arguments of subscribe() (what does `next` do? How does it differ from `callback`?)

Hmm, I was hoping https://github.com/WICG/observable#:~:text=The%20creator%20of,data%20is%20finished covered this sufficiently. Are the API shape / semantics really that opaque though? If so I suppose we could explain each input in more detail, although I would hate to duplicate too much of the IDL in the spec.

## Standards venue

I personally think this is the least consequential topic regarding our proposal, and its review, so I'd like to not spend much time on it. For one, nothing precludes us from moving things into, or using things from, TC39 in the future _if_ both communities really see this as absolutely necessary, as @littledan mentioned. AbortSignal/AbortController were standardized in WHATWG DOM, and there is some discussion today about being able to use these cancelation primitives from within TC39 world. That should be a solvable, backwards-compatible problem.

I'm not saying we'd design Observables with that path in mind. I'm saying that Observables and cancelation primitives have not gotten good footing in TC39, so they're being pursued elsewhere, and simultaneously they're not precluded from a future in TC39 world forever (should that eventually become necessary).

> @LeaVerou I've been suggesting to @domfarolino ever since I became aware of the browser effort that TC39 would be a better venue, but there's not been much discussion in plenary about it, since imo unless Chrome is willing to wait for the language to add Observables, our hands are kind of tied.

I certainly hope we wouldn't have to wait another 8 years!!

> @domfarolino I believe you already belong to an Ecma member company (Google) so it will be trivial for your lead delegate (Shu) to onboard you as a TC39 delegate.

Thank you, I will say though, Shu is supportive of our current path so I don't think we really need to make any sudden moves here. We're planning on standardizing it through WHATWG DOM.

[^1]: At least that's what I suspect the current `on()` method will turn into.

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

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