You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an aside to the discussion on #464 ... We might want to move all core operators directly onto the Observable itself.
I'm on the fence about this one.
It makes overriding operators for better performance on Observables like ScalarObservable and ArrayObservable more straightforward, and require less type checking in the operator implementations themselves.
It's less hacky. We'll no longer be mutating the prototype in a separate module from Observable for our main operators
It's unlikely most people will want to use an Observable with no operators.
... but I'll really want to trim down what is "core". For example, share() and multicast() should be core, since share is very commonly used, and multicast enables all other variants... but shareReplay, shareBehavior, publish, publishReplay, publishBehavior should probably not be "built in", IMO.
There is no point keeping share and leaving out shareReplay, shareBehavior, they are all equal specializations of multicast. Better just keep multicast.
If it can be done trivially with an existing operator or two, it's not core.
if it cannot be done trivially with an existing operator, it should be considered for core.
share === multicast(() => new Rx.Subject()) looks trivial, so share is not core (?).
I don't really know how RxJS is used in Netflix, neither in Angular2.
Neither do I! Actually, we right now only publish observables for component events, and for http requests. We don't consume them internally, except for in our examples. But the lighter the "core" set of operators can be, the better, as discussed in this issue.
In Typescript and with generated type definitions, the way the prototype is currently mutated doesn't complain internally, but also doesn't offer autocomplete or anything useful, which is sort of a bummer when y'all are making all this effort with Typescript and tooling.
Activity
benlesh commentedon Oct 6, 2015
attn @jeffbcross
staltz commentedon Oct 7, 2015
There is no point keeping
shareand leaving outshareReplay,shareBehavior, they are all equal specializations ofmulticast. Better just keepmulticast.share===multicast(() => new Rx.Subject())looks trivial, soshareis not core (?).benlesh commentedon Oct 7, 2015
I guess I'm unconvinced that they're as commonly used, even if they are very similar.
staltz commentedon Oct 7, 2015
In Cycle.js world, definitely. In other contexts, I don't really know how RxJS is used in Netflix, neither in Angular2.
jeffbcross commentedon Oct 8, 2015
Neither do I! Actually, we right now only publish observables for component events, and for http requests. We don't consume them internally, except for in our examples. But the lighter the "core" set of operators can be, the better, as discussed in this issue.
benlesh commentedon Oct 8, 2015
cc @steveorsomethin @jhusain
robwormald commentedon Oct 12, 2015
In Typescript and with generated type definitions, the way the prototype is currently mutated doesn't complain internally, but also doesn't offer autocomplete or anything useful, which is sort of a bummer when y'all are making all this effort with Typescript and tooling.
benlesh commentedon Oct 12, 2015
Yeah, we'll probably have to go back to at least adding stubs for every operator on the Observable type. It's just so ugly.
Part of me wonders if it might be better just to switch to ES6 and manually maintain the .d.ts files...
david-driscoll commentedon Nov 16, 2015
I've done some work to that effect, that makes consuming the typings easier, and all the stubs only have to go into the operators themselves.
#715
benlesh commentedon Nov 30, 2015
I think we've decided not to do this.