Intent to Prototype: Observable API

[Dominic Farolino]

Contact emails

d...@chromium.org

Explainer

https://github.com/WICG/observable

Specification

None

Summary

Observables are a popular reactive-programming paradigm to handle an asynchronous stream of push-based events. They can be thought of as Promises but for multiple events, and aim to do what Promises did for callbacks/nesting. That is, they allow ergonomic event handling by providing an "Observable" object that represents the asynchronous flow of events. You can "subscribe" to receive events as they come in, but more importantly, this object exposes a series of operators & combinators that let you to declaratively describe the flow of transformations through which events go. This is in contrast with the imperative version, which often requires complicated nesting with things like `addEventListener()`. For more on this, see the examples in the explainer. The big selling point for native Observables is their integration with EventTarget — its proposed `on()` method that returns an Observable which is a "better" `addEventListener()`. See https://github.com/WICG/observable and https://twitter.com/domfarolino/status/1684921351004430336. See the in-progress implementation design doc: https://docs.google.com/document/d/1NEobxgiQO-fTSocxJBqcOOOVZRmXcTFg9Iqrhebb7bg/edit

Blink component

Blink>DOM

Motivation

Promises gave web developers a synchronously-available handle representing a single value that will be available asynchronously later. This lets developers write linear, declarative-style flows that outline how an asynchronous value will eventually be handled, avoiding "callback" hell. The web does not have a good analogous primitive for an async *stream of multiple* events, and Observables finally brings this primitive to the web. They let you declaratively establish a pipeline of composable operators through which an asynchronous stream of events will flow. See the explainer and its examples for more.

Initial public proposal

https://github.com/whatwg/dom/issues/544 and https://github.com/WICG/observable

TAG review

https://github.com/w3ctag/design-reviews/issues/902

TAG review status

Pending

Risks

Interoperability and Compatibility

Our addition of a native EventTarget#on() method might collide with method names used by other libraries in the wild. However at the moment we're not sure this would collide with any EventTarget monkey-patching libraries, or even how serious this overall collision might be. See https://github.com/WICG/observable/issues/39.

Gecko: No signal

WebKit: No signal

Web developers: Strongly positive (https://twitter.com/domfarolino/status/1684921351004430336) Also see https://foolip.github.io/spec-reactions/ and the developer interest in the original WHATWG DOM issue.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

The developer experience of Observables might benefit from Observable-specific DevTools tracking of events and streams (see https://github.com/WICG/observable/issues/55). It is possible that the existing DevTools work that assists asynchronous task tracking and callstack tagging may be sufficient though. At the moment, however, our effort is focused on the platform implementation of Observables.

Is this feature fully tested by web-platform-tests?

No

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1485981

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5154593776599040

This intent message was generated by Chrome Platform Status.