Sharing Top Content from the Angular-sphere.

RxJS: When to Use switchMap – Angular In Depth

  • Here’s the NgRx effect: – And here’s the redux-observable epic: – The effect/epic debounces the user input so that backend searches are not performed for each keystroke and uses distinctUntilChanged so that no searches are performed unless the partial address has changed.
  • From the summarised recommendations in RxJS: Avoiding switchMap-Related Bugs, we know that: – concatMap could be used as a conservative choice;mergeMap should not be used — the ordering of the results is important;switchMap could be used — when a new search is made, pending results are no longer needed; andexhaustMap should not be used — searches…
  • Whether or not the behaviour differs depends upon two things: – the time it takes for the backend searches to be fulfilled; andthe time between the user’s keystrokes.The debounceTime operator imposes a limit on how frequently backend searches can occur, so unless the fulfilment of a search takes longer than…
  • Let’s look at the worst-case scenario: the searches take significantly longer than the debounce time to be fulfilled and the user types slowly, with intervals between keystrokes that slightly exceed the debounce time.
  • In the worst-case scenario, if concatMap is used, each keystroke effects a search and the results of that search will still be pending when the next key is pressed — so the next search will be queued.

Dealing with stale results in effects and epics

RxJS: When to Use switchMapPhoto by Geran de Klerk on UnsplashIn a response to RxJS: Avoiding switchMap-Related Bugs, Martin Hochel mentioned a classic use case for switchMap. For the use case to which he referred, switchMap is not only valid; it’s optimal. And it’s worth looking at why.

Dealing with stale resultsLet’s look at an example that involves an expensive call to a backend service: a search for addresses that match a partial address typed into an HTML input.

Here’s the NgRx effect:

And here’s the redux-observable epic:

The effect/epic debounces the user input so that backend searches are not performed for each keystroke and uses distinctUntilChanged so that no searches are performed unless the partial address has changed. The operator that’s then used to flatten the backend observable is switchMap.

Why?

From the summarised recommendations in RxJS: Avoiding switchMap-Related Bugs, we know that:

concatMap could be used as a conservative choice;mergeMap should not be used — the ordering of the results is important;switchMap could be used — when a new search is made, pending results are no longer needed; andexhaustMap should not be used — searches for new, partial addresses should not be ignored.So how would the behaviour differ if the effect/epic were to use the conservative choice of concatMap rather than switchMap?

Whether or not the behaviour differs depends upon two things:

the time it takes for the backend searches to be fulfilled; andthe time between the user’s…

RxJS: When to Use switchMap – Angular In Depth