Description
こんにちは TAG-さん!
I'm requesting a TAG review of Observables.
This proposal adds an .on() method to EventTarget that becomes a better addEventListener(); specifically it returns a new Observable
that adds a new event listener to the target when its subscribe() method is called. The Observable calls the subscriber's next() handler with each event.
Observables turn event handling, filtering, and termination, into an explicit, declarative flow that's easier to understand and compose than today's imperative version, which often requires nested calls to addEventListener() and hard-to-follow callback chains.
- Explainer (minimally containing user needs and example code): https://github.com/WICG/observable
- User research: We don't have "user research" per se, but the closest thing we have is a sense of how much developers (the direct users of this API) want it:
- https://twitter.com/domfarolino/status/1684921351004430336 got some terrific reception
- and https://foolip.github.io/spec-reactions/ shows that the original API proposal was the most-reacted to standards issue on GitHub
- Security and Privacy self-review: https://github.com/WICG/observable/blob/master/security-privacy-questionnaire.md
- GitHub repo (if you prefer feedback filed there): https://github.com/WICG/observable
- Primary contacts (and their relationship to the specification):
- @domfarolino (Google), @benlesh (RxJS maintainer) — both are co-authors of the proposal
- Organization/project driving the design: Both Google (@domfarolino) and open source maintainers personal time
- External status/issue trackers for this feature: https://chromestatus.com/feature/5154593776599040
Further details:
- I have reviewed the TAG's Web Platform Design Principles
- The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
- The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
- Existing major pieces of multi-stakeholder review or discussion of this design:
- Major unresolved issues with or opposition to this design: There are just a few big design questions remaining, see Why do some operators return Promises? WICG/observable#20, Is there any concern about the difference in constructor semantics from
Promise
? WICG/observable#22, Observables can be made async iterable by using a buffer WICG/observable#33 - This work is being funded by: Google I guess? Anyone contributing...
We'd prefer the TAG provide feedback as:
💬 leave review feedback as a comment in this issue and @-notify @domfarolino and @benlesh