RFC: A new way of "piping"

[benlesh]

Given the move away from lift: #7201 #7202

We can make our observable even more compatible with other observables by migrating us away from the pipe method. This is not something that would happen immediately, rather over a very, very long period. The idea is to increase compatibility and improve ergonomics.

Problem: It's annoying to have to from(x) types in order to use our operators with them

There's a common issue where people want to convert other things to observables in order to use our operators. Whether it's an array or a promise, there are times were you need to do from and the only reason you're doing it is because you want that .pipe method, and you want an observable to operate on.

Problem: pipe is a method

1. It's not tree shakable
2. It's unlikely to exist on "other observables".

The second one is more of a problem, honestly. If people implement code with the expectation that pipe exists as a method on whatever observable they get, then even while we've made sure our operators will work with any "same-shaped" observable, that custom code will break, because it's expecting pipe to be a method.

Proposal

A new rx method that accepts an ObservableInput as the first argument, and a rest of operators:

export function rx<A, B>(source: ObservableInput<A>, a: OperatorFunction<A, B>): Observable<B>;
export function rx<A, B, C>(source: ObservableInput<A>, a: OperatorFunction<A, B>, b: OperatorFunction<B, C>): Observable<C>;
export function rx<A, B, C, D>(source: ObservableInput<A>, a: OperatorFunction<A, B>, b: OperatorFunction<B, C>, c: OperatorFunction<C, D>): Observable<D>;
// ... and so on
export function rx<T>(source: ObservableInput<T>, ...operators: OperatorFunction<T, any>[]): Observable<unknown> {
  returm pipeArray(operators)(from(source))
}

(Technically, rx is just a standard functional pipe with some specific types, it could be the same pipe method we expose under the hood)

The usage would be as such:

import { rx, map, delay } from 'rxjs'


rx(source$, map(n => n + n)).subscribe(console.log)

// or

rx(somePromise, delay(1000)).subscribe(console.log)

// or

rx(someAsyncIterable, map(n => n + n)).subscribe(console.log)

// ...and so on.

Bonus? from could migrate to just be rx as well

For a long time people have complained about from being a horrible name for an exported function. (Although I do like import { from } from './from' in our codebase 😄). This would mean that couple could technically just do: rx(somePromise) and it's the same as from(somePromise).

[eduardoRoth]

I like the approach!

[TheLarkInn]

It's not tree shakable

💯

[UserGalileo]

Seems great!

Is "rx" the final proposed name? I know it'd be a breaking change, but what if...

import { pipe, flow } from "rxjs";

// Pipes a value into operators
const derived$ = pipe(source$, ...operators)

// Or any other name really. This is what the standalone "pipe" is at the moment.
const customOperator = flow(...operators)

Would it be too bad? 😬 Mentally, .pipe() works on an Observable, I've always found it strange that the standalone version does not!

[timdp]

• Why not call it pipe?
• if this is long-term, won't the pipeline operator materialize first?

[demensky]

pipe already exists.

[timdp]

pipeline a la Node.js then?

[jeremymwells]

Not sure how you'd use rx without a pipe concept to be able to tree shake it, but I think this is a great way to solve interop; I like the ergonomics. rx() also has the benefit of wrapping the behavior in something unambiguous.

[BaronVonPerko]

I like it. Ship it

[BigAB]

I know people would probably hate it, but have you considered a function that returns a function that would pipe the operator arguments and call the result with the observable passed.

rx(source$)(...operators)

[demensky]

One option is to simply make a function with 2 arguments (the second is an array):

rx(fromEvent(document.body, "mousemove"), [
  debounceTime(2),
  map(({ clientX }) => clientX),
  take(2),
  takeUntil(destroy$),
]);

Formatted by Prettier.

[benlesh]

I know people would probably hate it, but have you considered a function that returns a function that would pipe the operator arguments and call the result with the observable passed.

@BigAB why do you like this shape? Is there a use case?

[benlesh]

Why not call it pipe?

@timdp Because it's not really just a pipe. It's applying from to the first argument.

Technically it's pipe(source, from, map(fn), ...)