4 ms·

This proposal makes the same mistake as various stream implementations (including RxJS in the past) of making operators methods on the observable. This means y

This proposal makes the same mistake as various stream implementations (including RxJS in the past) of making operators methods on the observable. This means you can't add custom operators without subclassing or doing weird crap with proxies. When RxJS stopped using instance methods to implement operators, it opened up the ability to create custom, domain appropriate operators which I found key to writing comprehensible and maintainable code. We really need a `pipe` operator, at minimum. https://rxjs.dev/guide/operators#creating-custom-operators https://rxjs.dev/guide/operators#creating-custom-operators

azangru 3y ago
> This proposal makes the same mistake as various stream implementations (including RxJS in the past) of making operators methods on the observable. I don't think they are making a mistake. I am sure Ben knows what he is doing, given how it was he who refactored rxjs 5 with all operators being methods on the Observable, to rxjs 6 with pipeable operators. But, their objective is not to bring rxjs into the browser, but rather to bring the Observable primitive into the browser. And, like Array prototype, which has methods, Observable, in order to be even minimally useful, needs some methods, which they modelled after TC39 iterators, for the sake of consistency. They say: > We expect userland libraries to provide more niche operators that integrate with the Observable API central to this proposal, potentially shipping natively if they get enough momentum to graduate to the platform. But for this initial proposal, we'd like to restrict the set of operators to those that follow the precedent stated above, similar to how web platform APIs that are declared Setlike and Maplike have native properties inspired by TC39's Map and Set objects. Therefore we'd consider most discussion of expanding this set as out-of-scope for the initial proposal, suitable for discussion in an appendix. Any long tail of operators could conceivably follow along if there is support for the native Observable API presented in this explainer. As to > We really need a `pipe` operator, at minimum Maybe we don't. Note that in RxJS version 8, they have introduced a new way of piping observables, which is the rx function [0]. Maybe they are thinking of something similar for the browser. Or maybe they are thinking of using the native pipeline operator if it ever gets approved. In the meantime, for any complex manipulations on observables, users will probably still import relevant functions from libraries. 0 - https://github.com/ReactiveX/rxjs/issues/7203 https://github.com/ReactiveX/rxjs/issues/7203

azangru 3y ago

> This proposal makes the same mistake as various stream implementations (including RxJS in the past) of making operators methods on the observable. I don't think they are making a mistake. I am sure Ben knows what he is doing, given how it was he who refactored rxjs 5 with all operators being methods on the Observable, to rxjs 6 with pipeable operators. But, their objective is not to bring rxjs into the browser, but rather to bring the Observable primitive into the browser. And, like Array prototype, which has methods, Observable, in order to be even minimally useful, needs some methods, which they modelled after TC39 iterators, for the sake of consistency. They say: > We expect userland libraries to provide more niche operators that integrate with the Observable API central to this proposal, potentially shipping natively if they get enough momentum to graduate to the platform. But for this initial proposal, we'd like to restrict the set of operators to those that follow the precedent stated above, similar to how web platform APIs that are declared Setlike and Maplike have native properties inspired by TC39's Map and Set objects. Therefore we'd consider most discussion of expanding this set as out-of-scope for the initial proposal, suitable for discussion in an appendix. Any long tail of operators could conceivably follow along if there is support for the native Observable API presented in this explainer. As to > We really need a `pipe` operator, at minimum Maybe we don't. Note that in RxJS version 8, they have introduced a new way of piping observables, which is the rx function [0]. Maybe they are thinking of something similar for the browser. Or maybe they are thinking of using the native pipeline operator if it ever gets approved. In the meantime, for any complex manipulations on observables, users will probably still import relevant functions from libraries. 0 - https://github.com/ReactiveX/rxjs/issues/7203 https://github.com/ReactiveX/rxjs/issues/7203