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

Thanks so much for the very thorough response @benlesh. Some replies below:

> Note that there's no part of this that is the Observable constructor. At the time it was thought to be too contentious to introduce a way to create observables from scratch (although I do think that the platform would benefit from this primitive). However, I'm amenable to adding a way to create observables given new versions of them pop up in the wild in many notable libraries.

Interesting. We of course could move incrementally, introducing Observable-returning APIs before making Observables themselves fully constructible by JS, however I do see value in providing the full API as a primitive up front. https://w3ctag.github.io/design-principles/#constructors recommends something similar, which is good news too.

> Critically important safety if we're allowing people to create their own observables: A means of tearing down or finalizing the data producer in any terminal case above (the producer is done, there was an error, or the consumer no longer cares).

I agree with this requirement, but it doesn't seem unique to user-constructed observables, right? For example, if unsubscribing from the platform-constructed Observable returned by `EventTarget::on()` did _not_ remove the subscription from the list of event listeners, that seems like a leak. Are there _additional_ concerns here that are unique to user-constructed Observables?

> ### Observables in the DOM
> If you want to be able to accurately model what we can do with EventTarget, observables must be able to emit sychronously.

Thanks, the impact of being synchronous makes sense here, especially for events and cancelation. I agree that the sync semantics here are ideal and give the most flexibility.

> Subscriber implements that interface, and generally "wraps" some observer to add the safety in I talked about above.

Exactly, this is what I was asking about. Just wanted to make sure I understood the relationship between the two.

> Or binding the observation to the subscription so it can teardown.

Can you clarify this (who exactly is tearing down here)? I understand that if complete()/error() is called on the Subscriber/wrapped Observer, we'd want to unregister "the subscription" from the event source for clean-up (it doesn't make sense to keep listening for events and having the "safe" `Subscriber` object just _not_ call `next()` forever). Is that what you mean?

----

RE promises: It's good to know that this hasn't been seen as fraught territory so far in the Observable-using community, though I do agree that for something like an Observables MVP, the Promise-ifying APIs could probably be initially left out.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/544#issuecomment-1435173279
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/544/1435173279@github.com>