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
Given there's an issue to possibly add Observable.from to this API #28, and I think that's a good add, it's worth mentioning that in RxJS anywhere we accept an Observable we also accept anything that Observable.from would accept.
Basically anywhere we accept an Observable or a function returns an Observable that the functionality is processing (takeUntil or flatMap for example), it's totally fine to also allow anything that Observable.from could accept and just do that conversion for the user. It cleans up a lot of code to allow this.
The text was updated successfully, but these errors were encountered:
Generally the purpose of a .from method is to prevent that overloading - meaning, that users are forced to do the nice, explicit thing, and ensure they have a real Observable before using them as such.
Obviously any method could accept both sets of inputs by wrapping the observable-ish in Observable.from but I would not expect builtin methods to do that.
Given there's an issue to possibly add
Observable.from
to this API #28, and I think that's a good add, it's worth mentioning that in RxJS anywhere we accept anObservable
we also accept anything thatObservable.from
would accept.This is stemming from my comment about
takeUntil
here.Basically anywhere we accept an
Observable
or a function returns anObservable
that the functionality is processing (takeUntil
orflatMap
for example), it's totally fine to also allow anything thatObservable.from
could accept and just do that conversion for the user. It cleans up a lot of code to allow this.The text was updated successfully, but these errors were encountered: