This is indeed exciting!! How do you imagine developers adopting this before support is ubiquitous? Is there a "standard" polyfill developers are expected to use? Some feature-detection based patterns? Something else?
On Tuesday, February 25, 2025 at 6:17:01 AM UTC+1 Domenic Denicola wrote: > Very exciting! > > On Sat, Feb 22, 2025 at 6:25 AM Chromestatus < > ad...@cr-status.appspotmail.com> wrote: > >> 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 >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EDOM%22> >> >> 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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? 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 (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., 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 > > > https://github.com/WICG/observable/issues/177 looks like it might also > have compat impacts, right? Albeit only in error cases. (In fact, in cases > where there are two errors at once.) > > Do you think it might be worth making that change before shipping? > > >> >> >> 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 >> <https://chromestatus.com>. >> >> -- >> 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67b8ef25.2b0a0220.38f609.0192.GAE%40google.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/73aa2f6e-59c0-48d8-ac1b-dc10d0d4ce1fn%40chromium.org.
