Why not more closely follow RxJS?

[tronicboy1]

I am confused as this proposal looks like what RxJS was doing before it refactored to use pipe and OperatorFunctions to process data.

Don’t you think learning from the progress done on RxJS would be best? What was the reason why we changed to pipe?

Also, interoperability with RxJS would be crucial for any proposal as I think that community would be your best supporters.

[Jamesernator]

Don’t you think learning from the progress done on RxJS would be best? What was the reason why we changed to pipe?

pipe allows for highly effective tree shaking. This isn't really a concern for builtins as, well, they are builtin so don't need tree shaking.

Really .pipe would be useful for any value not just observables, however extending Object.prototype is untenable, so the pipeline proposal exists instead.

[benlesh]

Really, we don't need to tree-shake things that are already on the browser, and a simple, reusable pipe function allows for the same thing. RxJS 8 has the rx function that we're going to try to have "just work" with these observables.

In an ideal world the TC39 pipeline operator would make this easier, and it sort of does, but IMO it's less than ideal. We might see a bind operator come help out with these needs though.

function pipeThrough(source, ...operators) {
  return operators.reduce((prev, fn) => fn(prev), source);
}

pipeThrough(
  observable,
  someOperator(),
  someOtherOperator()
)
.subscribe(console.log)

Or in RxJS 8 (if these observables land):

import { rx, switchMap, retry } from 'rxjs';

rx(
  button.on('click'),
  switchMap(() => rx(fetch(url), retry()))
)
.subscribe(console.log)