Contact emails d...@chromium.org
Explainer https://github.com/WICG/observable Specification https://wicg.github.io/observable 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 this object to receive events as they come in, and call any of its operators/combinators 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 `when()` 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 spec https://wicg.github.io/observable/ and the design doc: https://docs.google.com/document/d/1NEobxgiQO-fTSocxJBqcOOOVZRmXcTFg9Iqrhebb7bg/edit. Blink component Blink>DOM TAG review https://github.com/w3ctag/design-reviews/issues/902 TAG review status Issues addressed Risks Interoperability and Compatibility Initially we proposed adding the `.on()` method to EventTarget, which was found to conflict with userland versions of the same method. The conflict was found to be too significant to justify shipping our native version of this API (see https://github.com/WICG/observable/issues/39) so we renamed it to `.when()` and we strongly believe this resolves any naming collision issues after searching through public libraries and performing developer outreach on X. See the discussion on that issue. Gecko: No signal (https://github.com/mozilla/standards-positions/issues/945) WebKit: Positive (https://github.com/WebKit/standards-positions/issues/292) 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: We've gotten good design feedback from TC39 members on many issues which we have implemented accordingly. This has led to positive feedback from Node.js, and luke-warm non-negative feedback from WinterCG. See https://github.com/WICG/observable/issues/93; specifically https://github.com/nodejs/standards-positions/issues/1 & https://github.com/WICG/observable/issues/30 for Node, and https://github.com/wintercg/proposal-minimum-common-api/issues/72 for WinterCG. 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. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Yes See https://wpt.fyi/results/dom/observable/tentative. Flag name on about://flags observable-api Finch feature name ObservableAPI Requires code in //chrome? False Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1485981 Estimated milestones Shipping on desktop 135 Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (eg links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (eg, changing to naming or structure of the API in a non-backward-compatible way). Issues with the "possible future enhancement" label [1] track possible changes to the feature that may come after we ship the initial API. One issue (https://github.com/WICG/observable/issues/200) is identified to have behavior changes that theoretically pose a compat risk, but only for developers that subclass the API. The behavior change proposed puts the implementation more inline with what subclass users want: the operators that return native Observable objects would instead return objects of `this.constructor` type, as to return instances of the subclass that the operators are called on. This is how JS built-ins like `Array` work, however, no other web platform feature works like this and it likely requires non-trivial Web IDL support. [1]: https://github.com/WICG/observable/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22possible%20future%20enhancement%22 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5154593776599040?gate=5141110901178368 Links to previous Intent discussions Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykBH1%3DUoLN6%3DBRSEZE%2B1iUq6UdcTpo3qtTQ5T%3DSRxwnu5Q%40mail.gmail.com This intent message was generated by Chrome Platform Status. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67b8ef25.2b0a0220.38f609.0192.GAE%40google.com.
