The Ultimate Guide to Understanding All Flavours of switchMap

Thinking reactively is one of the most valuable skill that a web developer may possess, at least in my humble opinion. Fabulous library RxJS can help with it. Developing user interfaces is all about managing streams of information. Everything that happens on the page is a some kind of stream like:

• user inputs,
• networking,
• sensor events,
• etc.

However, many people unfairly claim that rxjs is too complicated, that it's hard to use and understand providing switchMap and its siblings mergeMap, concatMap and exhaustMap as scary example that should convince you how everything is unbearably overcomplicated. The phrase higher order observable makes some juniors crumble.

The official documentation about switchMap operator says:

Projects each source value to an Observable which is merged in the output Observable, emitting values only from the most recently projected Observable.

Sounds scary, not gonna lie. However, the definition is much more complicated than what this operator actually does.

There are million articles and videos on the Internet explaining flattening operators. My favourite is this one. Recent video from Joshua Morony is nice too. I hope that I can add my two cents here.

Without further ado, let's understand what are we mapping and where the switch is. Let's follow a simple example that perfectly illustrates how those operators act.

Imagine that you are the boss and you've got an assistant. During the day the boss gives different tasks to the assistant like make cup of coffee, plan a business trip, schedule a meeting with client, etc. Those tasks arrive unevenly during the working day. The assistant gets a task and decides how to fulfil it. E.g. for coffee they need to:

1. Go to the kitchen
2. Take a mug
3. Pour coffee
4. Bring it back to the boss.

Each task involves steps that take place over a period of time. All in all, the boss wants to know what the assistant has been doing during the day.

What can we say about those processes in terms of streams? Tasks from the boss is obviously a stream. The act of mapping the input task into sequence of actions to execute by the assistant is where the map part of each operator lies. In other words, the assistant hears "Make me a cup of coffee" and maps this command into several steps to be done.

What about switch, concat, merge, exhaust? As long as the assistant completes current task before the next one arrives everything is hunky-dory. However, what if assistant still works on the previous task when suddenly a new request from the boss arrives? Here's where they have to make a decision.

Let's discover what options are available:

1. The most obvious one is to stop doing current task and switch to a new one.
2. Be a hard working person, complete the current one, once it's completed move on to the next ie concat.
3. Or vice versa, pretend not to hear what the boss said and just exhaust new tasks while the current one is not completed.
4. Enter crazy mode and merge everything. Pour coffee while booking tickets to business trip. But the boss should be careful with never ending tasks in this case like sorting out mail. It may ruin entire assistant's day.

And that's basically it. The stream of tasks where each task contains stream of actions is called Higher order observable in terms of Rx. The decision that the assistant took how to treat incoming tasks if the current one in not completed is called flattening strategy and almost all possible situations are covered by the library.