Responding to Yoav below: 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?
Great question. RxJS, the main userland Observable library, is working to provide a polyfill <https://github.com/ReactiveX/rxjs/issues/6367#issuecomment-2442979744> (also see this post <https://x.com/BenLesh/status/1893764537364386223>) for folks to use. And the next major version of RxJS will also be backwards compatible with the native implementation, per https://x.com/BenLesh/status/1893053275995357608 and https://github.com/ReactiveX/rxjs/issues/6367. On Wed, Feb 26, 2025 at 3:39 PM Dominic Farolino <d...@chromium.org> wrote: > https://codepen.io/jaffathecake/pen/raNWMmK?editors=0012 - it seems >> inconsistent that two of the calls to ob.map create a new subscriber, >> whereas the other picks up the observable half way through. > > > Right, the idea that a subscription doesn't have side effects if an > existing subscription is in-flight was essentially the outcome of > https://github.com/WICG/observable/issues/170 & > https://github.com/WICG/observable/issues/178. The alternative, where > producer:consumer are 1:1, made it easy to write performance foot-guns > where what you actually want is to tap into an existing stream of values > without paying the cost of setting it up each time if it already exists. > Many userland Observables inevitably get `share()` slapped on them > somewhere in the chain to alleviate this, but the inconsistency made it > hard to judge whether your subscription would have side-effects or not. We > also saw a lot of Observable learning material was taking pains to caveat > <https://ronnieschaniel.com/rxjs/rxjs-mastery-hot-vs-cold-observables/#:~:text=Why%20do%20we%20need%20cold%20and%20hot%20Observables%20in%20RxJS%3F> > right > away, this unintuitive idea that the Observable type itself doesn't > represent anything but a stateless subscription vendor. Now it basically > represents the producer, and I think that matches peoples' mental models > <https://github.com/WICG/observable/issues/178#issuecomment-2480525113>. > > I guess the rule is: A new subscriber is created if the observer has >> closed, but isn't this really inconsistent? > > > I think it is consistent though, no? It's true that it's neither "only one > call to the subscriber" nor "each call to the initial observable initiates > a new subscription". But it is similar to what you wrote above: a > subscriber is invoked/spun up if its subscription is closed (not observer). > The pay-off is that you know you're never going to have "extra" side > effects when subscribing. At most you will spin up a single producer (which > you're OK with since you're subscribing), and at best you will listen in on > an existing one. If you need a new subscriber to be created on each > subscription, you'll need to basically take a closure over the > Observable-vending API and call each `subscribe()` on it, which I hope is > not too burdensome. > > On Wed, Feb 26, 2025 at 2:55 PM Jake Archibald <jaffathec...@gmail.com> > wrote: > >> I'm struggling a little to get my head around how this works. >> >> https://codepen.io/jaffathecake/pen/raNWMmK?editors=0012 - it seems >> inconsistent that two of the calls to ob.map create a new subscriber, >> whereas the other picks up the observable half way through. >> >> If I put the .complete call in a setTimeout, then there's only one >> subscriber created. >> >> I guess the rule is: A new subscriber is created if the observer has >> closed, but isn't this really inconsistent? >> >> I'd expect it to be one way or the other. As in: >> >> There's only one call to the subscriber. >> Or >> Each call to the initial observable is a new subscription. >> >> The way it's neither one or the other is confusing to me. But maybe >> that's totally normal for folks who are used to observables? >> >> On Friday, 21 February 2025 at 21:25:05 UTC Chromestatus 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 >>> >>> 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/CAP-uykAesLesKiCVpBsHEqw9xcX-_RyeekCMEDHGJxZXDqpBWQ%40mail.gmail.com.
