Interop with Native Observables

[dariomannu]

What are the current thoughts around making future RxJS work with the WICG Observables?

I can see a few important considerations to be made here and I'd love to hear some more from the community:

1. Rx moved away from operators as instance methods but WICG stuck with those
   a. Should RxJS revert back to operators as instance methods?

   • No monkey-patching global Observables, guess everyone agrees on that?
     Maybe an export RxObservable extends Observable {} with the added operators?

   • Tree-shaking is lost again if using instance methods.
     However, other libraries like prebid.js have always had their own build process that makes it possible to add a json file and configure the build process to only include the modules that are actually required.
     Should RxJS adopt a similar concept, in case, so that only the required operators would be built inside node_modules or other dist bundles, where classic tree-shaking won't cut it?
     This would require devs supplying some rx.config.json with the list of operators to be built in (instead of some pre-defined ones, or separate packages to use like import 'rx/popular' or import 'rx/full'?),
     There's no free lunch here anyway, but this could possibly be more reliable than some tree-shaking tools I've seen around still leave unused code in bundles for no reason I could understand.

   b. Should we continue to have operators as functions and keep the new Rx8 pattern like rx(...stuff) instead?

   • Can we/shall we have lettable operators work like the pipe() function (not the .pipe method!) for currying with Native Observables like in const stream = rx(...ops); const source = document.when('event'); stream(source).subscribe(sink);?
     That may turn into an interesting mix of native instance operators chained with function operators and other native instance operators... I've got a feeling it might work just fine:
     (source) [.native operators] [|> piped function operators] [.more native operators]
     this should work fine because each operator would now return a new Native Observable (or polyfill), so the new Rx.map would be implemented I guess as a (fn) => (source) => source.map(fn), even if we then use the whole thing as rx(source, map, inspect, scan, ...)

2. How should devs create custom operators, if there's no native .pipe()?
   Should .pipe() come back in the "extended" Rx Observable?

   a. If Rx extends Observable, devs could then extend Rx, using the same pattern to add custom operators
   without the need for .pipe(). How would that sound?
   const CustomObservable extends RxObservable {...customStuff}

   b. If operators are just functions, taking observables and returning observables, creating custom ones should be as simple as any (...args) => (source) => new Observable(() => ...whatever) and fit in the above mix of native/non-native mix in 1.b.1

3. In day-to-day development, the "component" has become a fundamental building block and design pattern
   (React, Angular, Vue, Lit, Rimmel, whatever). There is an important challenge here, because:

   a. When we define a component in code, what we do is we define a processing pipeline,
   something like [ event source => ...operators => sinks ]

   b. However, when using the WICG proposal, we don't have any observable available yet
   until EventTarget.when(...) is called on mount.
   We normally define components before the observable we want to call instance methods of is instantiated, right?
   So that's a bit far from ideal.

4. Points 1, 2, 3 were mostly focusing on front-end UI observables, but suppose we wanted to create a node.js framework like Express or Fastify but using native Observables, we may face the same issue 3.b like above, as we'd still define server-side routes before any request.when('data') or websocket.when('data') is called.

5. Subject and Behavior are not in the WICG spec but they might be added later.
   These I guess should still be provided of RxJS until (if) they get standardised, but:
   Subject.operator1().operator2() should return a Subject, not just an Observable (see Subject + operators should return another Subject, not an Observable #7547)

[dariomannu]

Here's a little study of one way lettable operators might work in conjunction with native and user-defined ones, without monkey-patching or extending the Observable class.

For example, map() is implemented as a wrapper deferring to the native .map.

The compose function used here is using an Observature-inspired addSource method to help frameworks bind to native observables, as above, as soon as they become available on mount, using their native instance methods and without having to use an intermediate Subject (sure I've lost some people wondering why would we need one at all) in the component.

In a way or another, I feel this could be one of the best ways to use native Observables in a framework context. Comments appreciated