The RxJS concatenation strategies, pt 4/4

Welcome to the last part of this small journey regarding the RxJS concatenation strategies.

Before getting further into reading, ensure to have read the previous articles, to have a better understanding of the context.

Part 1 concatMap strategy

Part 2 mergeMap strategy

Part 3 switchMap strategy

Today we’ll cover the last one, the exhaustMap strategy. Have a glance to its marble table:

Here we have our “usual” streams of events, we assume that the first one above is a stream of events emitted by an imaginary user, which types in a as much imaginary text input the values “1” , “3”, and “5”, each value separated by a certain amount of time, let’s say that the value “3” is typed one second and a half later than “1”, and the value “5” is typed just one second later than “3”.

Then, at each value typed, our RxJS operator exhaustMap creates, concatenates and schedules 3 different events one each half a second, which value is the value typed in multiplied by 10, and is finally emitted as a GET request.

So, if a user types “1”, there will be three HTTP GET request one each half a second:

[GET] /endpoint/10 at 0s

[GET] /endpoint/10 at 0.5s

[GET] /endpoint/10 at 1.0s

Now, let’s say that the user, after 1.5 seconds, types “3” in our text box: our RxJS operator exhaustMap concatenates the three HTTP calls and schedules them as previously said, but after about a second, the user types “5”.

Differently from other operators, in this case we’ll have the expected three HTTP calls [GET] /endpoint/50 ignored, since the previous event hasn’t finished yet.

This could be particularly useful for example in payments forms: we absolutely don’t want that the user clicks multiple times on our payment button and pays again and again (do we? 😛).

Once the user clicks on the button, the exhaustMap simply ignores all the other events emitted if the ongoing event hasn’t finished yet.

I hope that this operator is a bit more clearer now :)

Thanks for reading!