The rxjava doc definition of switchmap is rather vague and it links to the same page as flatmap. What is the difference between the two operators?
相关问题
- “Buffer until quiet” behavior from Reactive?
- How to execute 2 Observables in parallel, ignoring
- How to properly stop rxjava Flowable?
- Rx Buffer with timeout since first new group eleme
- Optional Observables in combineLatest
相关文章
- Spring 5 Web Reactive - Hot Publishing - How to us
- RxJava takeUntil with emmision of last item?
- Error handling for zipped observables
- How does RxJava Observable “Iteration” work?
- What is Subject.asObservable good for?
- Cannot resolve method Observable.from in rxjava 2
- Catch error if retryWhen:s retries runs out
- How to transform rx_tap of UIButton to a network r
I came across this when implementing "instant search" - i.e. when user types in a text box, and results appear in near real-time with each key stroke. The solution seems to be:
With flatMap, the search results could be stale, because search responses may come back out of order. To fix this, switchMap should be used, since it ensures that an old observable is unsubscribed once a newer one is provided.
So, in summary, flatMap should be used when all results matter, regardless of their timing, and switchMap should be used when only results from the last Observable matter.
Here is the one more - 101 line long example. That explains the thing for me.
Like was said: it gets the last observable (the slowest one if you will) and ignores the rest.
As a result:
You see the A got ignored.
No flatMap discussion is complete without comparing and contrasting with
switchMap
,concatMap
andconcatMapEager
.All of these methods take a
Func1
that transform the stream intoObservable
s which are then emitted; the difference is when the returnedObservable
s are subscribed and unsubscribed to, and if and when those the emissions of thoseObservable
s are emitted by the____Map
operator in question.flatMap
subscribes to as many emittedObservable
s as possible. (It is a platform dependant number. i.e. a lower number on Android) Use this when order is NOT important, and you want emissions ASAP.concatMap
subscribes to the firstObservable
and only subscribes to the nextObservable
when the previous one has completed. Use this when order is important and you want to conserve resources. A perfect example is deferring a network call by checking the cache first. That may typically be followed by a.first()
or.takeFirst()
to avoid doing unnecessary work.http://blog.danlew.net/2015/06/22/loading-data-from-multiple-sources-with-rxjava/
concatMapEager
works much the same but subscribes to as many as possible (platform dependant) but will only emit once the previousObservable
has completed. Perfect when you have a lot of parallel-processing that needs to be done, but (unlike flatMap) you want to maintain the original order.switchMap
will subscribe to the lastObservable
it encounters and unsubscribe from all previousObservable
s. This is perfect for cases like search-suggestions: once a user has changed their search query, the old request is no longer of any interest, so it is unsubscribed, and a well behaved Api end-point will cancel the network request.If you are returning
Observable
s that don'tsubscribeOn
another thread, all of the above methods may behave much the same. The interesting, and useful behaviour emerges when you allow the nestedObservable
s to act on their own threads. Then you can get get a lot of benefits from parallel processing, and intelligently unsubscribing or not subscribing fromObservable
s that don't interest yourSubscriber
samb
may also be of interest. Given any number ofObservable
s it emits the same items that the firstObservable
to emit anything emits. That could be useful when you have multiple sources that could/should return the same thing and you want performance. e.g. sorting, you mightamb
a quick-sort with a merge-sort and use whichever was faster.According to the documentation ( http://reactivex.io/documentation/operators/flatmap.html )
the
switchMap
is like theflatMap
, but it will only emit items from the new observable until a new event is emitted from the source observable.The marble diagram shows it well. Notice the difference in the diagrams:
In
switchMap
the second original emission (green marble) does not emit its second mapped emission (green square), since the third original emission (blue marble) has begun and already emitted its first mapped emission (blue diamond). In other words, only the first of two mapped green emissions happens; no green square is emitted because the blue diamond beat it.In
flatMap
, all mapped results will be emitted, even if they're "stale". In other words, both first and second of the mapped green emissions happen -- a green square would've been emitted (if they used consistent map function; since they did not, you see the second green diamond, even though it is emitted after the first blue diamond)switchMap
flatMap
If you´re looking for an example code
You can see more examples here https://github.com/politrons/reactive
switchMap was once called flatMapLatest in RxJS 4.
It basically just passes on the events from the latest Observable and unsubscribes from the previous one.