Consistency with RxJS (and interop)

[jayphelps]

What are your thoughts on Flowable's API compared to the latest RxJS? (v6 as of this writing, v4 API used to be very similar to Flowable)

The biggest differences off hand:

• RxJS uses pipeable operators e.g. source.pipe(take(1)) instead of prototype methods like Flowable (and old versions of RxJS). See here why.
• RxJS uses next() error() complete() instead of onNext() onError() onComplete(). This was changed a while ago because Observable was (technically still is) being proposed as an addition to the TC39 ECMAScript standard and that's what they wanted. Even though the standard is effectively dead at the moment, the rename ship has long since sailed. RxJS also supports a shorthand overload .subscribe(nextFn, errorFn, completeFn) passing them as arguments instead of passing an object with those names--Flowable supports just .subscribe(nextFn) overload.

Biggest reason I'm bringing up is I would imagine a dev using Flowable would also use RxJS, and having things consistent makes for a better DX.

Having a toObservable() method would also be handy for cases where you don't want to handle backpressure, but alternatively (or in addition) RxJS could support consuming Flowable via import { from } from 'rxjs'; from(flowable).subscribe(...)

I imagine this has been discussed internally, but couldn't find anything publicly.

[jayphelps]

More cruising led me to find that Netifi's JS lib adds toObservable interop: https://github.com/netifi/netifi-js-client/blob/3ec310824f643d61a8a6386458ff95524f3373a8/src/rx/FlowableAdapter.js#L35-L47

[josephsavona]

I’m no longer actively involved in development of this library but aligning w the RxJS api makes sense. When we first wrote the Flowable library, RxJS and the Observable spec proposal was still in flux and it wasn’t clear whether to go w the onNext() or next() style naming. ”pipeable” operators also seem fine, they certainly solve some issues and my only concern is that it would introduce a bit of perf overhead.

The main thing to figure out is if a migration plan is possible or necessary.

[OlegDokuka]

@jayphelps I'm working right now on reactive-streams-js. Once it is done I'm planning to get rid of Flowable/Single since they are handmade. Since RS Spec is the standard - interop is guaranteed by the set of rules so interop with others RS spec based libs will be implicit. E.g it will be easy to use Reactor-JS or have an adapter to RxJS world

[JWood48]

is there any progress on this issue?

[OlegDokuka]

I started the work in that direction and have already created the first bits -> https://github.com/rsocket/rsocket-js/pull/104. The next PR will be on the integration with Observable

[viglucci]

It's been awhile since this issue was opened, so some things have developed. I suspect that moving forward, the RxJS interop conversation will happen in relation to #158. We've already implemented an initial "adapter" that provides interop via the below:

• adapter: https://github.com/rsocket/rsocket-js/tree/1.0.x/packages/rsocket-adapter-rxjs
• example in use: https://github.com/rsocket/rsocket-js/blob/1.0.x/packages/rsocket-examples/src/rxjs/ClientServerCompositeMetadataRouteExample.ts

I'll wait to close or progress this issue further until we have a published 1.0.0-alpha version where the adapter can be exercised by consumers.