Observable

[keithamus]

WebKittens

@annevk

Title of the spec

Observable

URL to the spec

https://wicg.github.io/observable/

URL to the spec's repository

https://github.com/WICG/observable

Issue Tracker URL

https://github.com/WICG/observable/issues

Explainer URL

https://github.com/WICG/observable/blob/master/README.md

TAG Design Review URL

w3ctag/design-reviews#902

Mozilla standards-positions issue URL

mozilla/standards-positions#945

WebKit Bugzilla URL

https://bugs.webkit.org/show_bug.cgi?id=266843

Radar URL

No response

Description

This is a new object data type. It also has extensions to the event interface. It was discussed at the most recent TPAC. Chrome has an implementation for evaluation.

/cc @domfarolino

[nt1m]

cc @cdumez @rniwa @Constellation

[annevk]

https://github.com/WICG/observable?tab=readme-ov-file#userland-libraries is really great to see. There's not many proposals that have such strong evidence for demand.

One thing colleagues and I were wondering about is whether this has been presented to/discussed with TC39 again more recently? As with Streams it might well be reasonable to standardize this elsewhere, but it would be good to solicit their technical feedback. (I did just notice the outreach in wintercg/proposal-minimum-common-api#72 which seems great!)

@esprehn I noticed feedback from you at https://x.com/ElliottZ/status/1685171508501716993 that never made it into the issue tracker. Is that still something you feel strongly about?

[domfarolino]

whether this has been presented to/discussed with TC39 again more recently?

No it hasn't. I had discussed with @littledan the possibility of bringing this to some TC39 meetings, which I need to follow up on!

[esprehn]

@annevk That feedback wasn't captured in a bug yet, but I can file one.

I also want to flag that linked the linked "userland-libraries" section seems like it might be (greatly) overestimating what things are Observables. It associates everything that has a subscribe(callback: (value: T) => void): () => void API as being the same contract as the spec, but proposes an API which not that (uses the Observable next/complete/etc. pattern).

[domfarolino]

It associates everything that has a subscribe(callback: (value: T) => void): () => void API as being the same contract as the spec.

Hmm, I guess it's true we list these things out as "observables", but I don't think we sell them as drop-in, API-compatible/conformant replacements for our API. For full transparency, in the very early iterations of the repository I do think we over-sold how many userland implementations matched the so-called "Observable contract" though. See WICG/observable#8 for discussion on this, including WICG/observable#8 (comment) where @benlesh further elaborates on the similarity between a few existing userland libraries listed, and our proposal.

but proposes an API which not that (uses the Observable next/complete/etc. pattern).

I don't follow this part.

[annevk]

@esprehn are you still planning to file that feedback?

[esprehn]

Yup, I filed a bug on the Observables repo.

[esprehn]

As an update on this I'm supportive of the direction in WICG/observable#178. I think a ref counted observable with async teardown (ex. in microtask or tasks) to avoid resubscription churn is a good compromise that addresses many of the sharp edges. It strikes a good balance between the predictability I've been advocating for, and the flexibility Ben Lesh has been advocating for.

[annevk]

Thank you @esprehn.

Colleagues and I think this makes for a good addition to the web platform and as such I suggest resolving this as "position: support" one week from now.

I do have one remaining concern around the venue. It seems this should be part of the WHATWG DOM Workstream. TC39 could also work, but that might be more work given AbortSignal and EventTarget object abstractions would be needed.