DEV Community: Leonardo Maria Miliacca

The RxJS concatenation strategies, pt 4/4

Leonardo Maria Miliacca — Wed, 01 Apr 2020 12:41:43 +0000

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!

The RxJS concatenation strategies, pt 3/4

Leonardo Maria Miliacca — Wed, 01 Apr 2020 07:52:32 +0000

Welcome back! In this article I’ll illustrate another concatenation strategy used by the marvelous library RxJS.
First and foremost, if you didn’t checked out my previous articles, I suggest to do that now:

concatMap

mergeMap

In this article I’ll introduce you to the switchMap operator, which basically lets the developer to concatenate different events such that if an event in the events chain hasn’t completed, is erased when a new event is emitted.

Let’s look at the switchMap marble diagram:

To put that in a living example, let’s say that when a user type a letter (“A”, “B”, “C” in our case), the switchMap operators combines it with 1,2 and 3, and emits these value with an interval of 1 second.

Now, let’s suppose that the user types “A”, switchMap register the three new values “A1”, “A2”, and “A3” and emits “A1” immediately, then waits for a second before emitting “A2”. In the meantime, after (about) 0.8 seconds, the user types in “B”. The switchMap operator cancels all the scheduled events “A2” and “A3”, and replaces them with a new serie of “B1” (which is emitted immediately), “B2” and “B3”.

This operator is particularly useful when we have a form which perform a save at each value change. To avoid tenths of HTTP request calls, we’d probably want to use switchMap.

I hope the mechanism is a bit more clearer :)

The RxJS concatenation strategies, pt 2/4

Leonardo Maria Miliacca — Tue, 31 Mar 2020 07:50:58 +0000

The previous article of this mini-serie was about the first concatenation strategy in the amazing RxJS world, which was a direct sequential events concatenation.

Today, I’ll dig deep into the mergeMap merging strategy.

Differently enough from the concatMap , which enqueues all the events by the input events’ order, the mergeMap operator emits events by overlapping the order. Let’s see the marble diagram below:

Here let’s suppose that a user types in “A”, “B” ** and **“C” in a textbox attached to a Subject that emits values.

Plus, there is another Subject that takes in a stream of values, and emits three new values combining the letter typed by the user and a sequential number (1,2,3) in an interval of a second each.

So, if a user types “A”, the value emitted immediately will be “A1”, then “A2” after a second, and finally “A3” after three seconds.

Here, there isn’t a proper concatenation, is more like attaining to the word meaning: it’s merging all the emissions consequently, even if the event before hasn’t finished and even if they're overlapping each other.

This is especially true with HTTP requests. In this case, if we consider A1, A2, A3, B1 and so on as HTTP requests, they will be started consequently, and A2 will be started even if A1 isn’t completed.

Hope that this merging strategy is a bit more clearer now.
The next article will talk about the next concatenation strategy: switching.

The RxJS concatenation strategies, pt 1/4

Leonardo Maria Miliacca — Mon, 30 Mar 2020 09:17:23 +0000

As my journey into the marvelous world of RxJS goes on, I want to share a bit of knowledge I’ve got following courses, blogs and so on regarding the concatenation strategies.
First off, what is a concatenation strategy?
As you may probably know, RxJS is about streams of values, often handled asynchronously, as HTTP calls can be, that’s why it can happen that we have to use some sort of concatenation to keep our code execution in order, let’s see how.
Let’s put that we have a text box where we freely type anything, and that at each input typed by the user, we are sending 3 HTTP requests to a server, combining the letter typed with the numbers 1,2 and 3, and so on with every letter typed. In other words, if the user types “A”, the client will send three requests like:

[GET] /endpoint/A1

[GET] /endpoint/A2

[GET] /endpoint/A3

FIRST STRATEGY: concatMap
Given a stream of value (the user that types n times), the concatMap operator waits for each operation before initializing the next one.

Given our example above, the marble diagram here shows the first stream of values (A, B and C) which represent the values emitted by the user, and the stream 1,2 and 3 which represent our merge (“A1” , “A2” and so on).
Let’s follow step by step:
The user types A, and the value first merged value is emitted as a [GET]/endpoint/A1 , when the request is resolved then…

…the client starts [GET]/endpoint/A2 , when resolved then…

… the client starts [GET]/endpoint/A3, when resolved then…

…User types B, then…

[GET]/endpoint/B1 starts, and once resolved…

…[GET]/endpoint/B2 starts but…

…In the meantime the user types C, but our concatMap enqueues C1, C2, and C3 after B3 emission, so…

… [GET]/endpoint/B3 starts, and once resolved…

… [GET]/endpoint/C1 starts, and once resolved…

… [GET]/endpoint/C2 starts, and once resolved…

… [GET]/endpoint/C3 starts

Now even displacing B much much before the result won’t change, as you can se in this edited marble diagram below.

And that’s pretty much it!

I hope that this concatenation strategy is a bit clearer :)