Closed tronicboy1 closed 1 year ago
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.
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)
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.