DEV Community: Jan-Niklas Wortmann

Announcing the Alpha Release of xstate-ngx!

Jan-Niklas Wortmann — Fri, 05 Jul 2024 15:09:43 +0000

I am very excited to announce the alpha release of xstate-ngx! This marks a significant milestone in integrating XState with Angular, and I can't wait for you to try it out and share your feedback.

For now, the project is published under xstate-ngx. However, we're planning to move it into the official XState monorepo once discussions are finalized and your feedback has been implemented. You can track the progress and discussions in the related PR.

What is xstate-ngx

You might be wondering, what is xstate-ngx?! The official xstate documentation says the following:

XState is a state management and orchestration solution for JavaScript and TypeScript apps.
It uses event-driven programming, state machines, statecharts, and the actor model to handle complex logic in predictable, robust, and visual ways. XState provides a powerful and flexible way to manage application and workflow state by allowing developers to model logic as actors and state machines. It integrates well with React, Vue, Svelte, and [...]

and now there is an angular integration! xstate-ngx uses the primitives that XState provides and provides a thin wrapper to utilize Angular's Dependency Injection mechanism and signals.

Why Alpha?

This alpha release aims to give you a taste of the developer experience with xstate-ngx. I want you to play with it, explore its capabilities, and most importantly, provide feedback on the general API design. Your input is crucial in shaping the future of this integration.

Getting Started

To help you get started, we've provided several examples on GitHub. Here's a quick highlight of how you can use xstate-ngx in your projects:

Example: Simple Toggle Machine

import { createMachine, interpret } from 'xstate';
import { useMachine } from 'xstate-ngx';
import { Component, inject } from '@angular/core';

// Define your machine
const toggleMachine = createMachine({
    id: 'toggle',
    initial: 'inactive',
    states: {
        inactive: {
            on: { TOGGLE: 'active' },
        },
        active: {
            on: { TOGGLE: 'inactive' },
        },
    },
});

const ToggleMachineService = useMachine(toggleMachine);

@Component({
    selector: 'app-toggle',
        providers: [ToggleMachineService],
    template: `
        <button (click)="toggleMachine.send('TOGGLE')">
            {{ toggleMachine.snapshot().value === 'inactive' ? 'Off' : 'On' }}
        </button>
    `,
        standalone: true
})
export class ToggleComponent {
    protected toggleMachine = inject(ToggleMachineService)
}

In this example, we define a simple toggle state machine and create an Injectable using useMachine from xstate-ngx. The returned Service can then be used in a component. The snapshot property is a signal allowing for fine-grained reactivity, but also enabling to easily derive state by using the compute function.

Special Thanks

I couldn't have reached this milestone without the invaluable contributions and support from the community:

Enea Jahollari and Chau Tran for their first round of feedback.
David Khourshid and Mateusz Burzyński for their outstanding work on XState, their interest in an Angular implementation, and their insightful discussions about this topic.
The design and implementation are heavily inspired by NgRx Signals, so many thanks to the NgRx team!

Join the Conversation

Your feedback is essential to us. Join the conversation, try out the alpha release, and let us know your thoughts. For now the best place to share any kind of feedback is the xstate-angular repository. Together, we can make xstate-ngx a robust and delightful tool for the Angular community.

Let me know what you think and happy coding!

An Introduction to Pact and Consumer-Driven Contract Testing

Jan-Niklas Wortmann — Tue, 03 Nov 2020 16:42:15 +0000

E2E Testing is difficult, definitely one of the most difficult challenges within front-end development. UI tests tend to be flaky, but depending on your risk assessment you probably want to have the confidence E2E tests provide. But have you considered Consumer-Driven-Contract Testing? It is an automated testing approach to test the API integration of distributed systems, promising fast feedback and eliminating flaky integration tests. One tool providing these benefits and enabling you to write Consumer-Driven Contract Tests is Pact.

Spoiler: This is the first part of a series of blog posts taking an in-depth look into Consumer-Driven Contract Testing with Pact particularly for JavaScript Developers.

What is Consumer Driven-Contract Testing?

Splitting the word "Consumer-Driven Contract Testing" apart helps in understanding this testing approach. Let's first have a look at the term "Contract Testing". A Contract in this instance refers to some kind of specification describing the behavior of an HTTP based API. This specification can be in different formats and depends on the concrete implementation of Contract Testing. You can think of it as some kind of swagger.json or an OpenAPI specification if you are familiar with those. Usually such a contract specifies a REST-API, though it is not limited to that. So "Contract Testing" is a testing approach that uses the API specification to test the provider of the API but also the consumer of the API in isolation. We will talk about this more in detail later on in the concrete example of how Pact implements Consumer-Driven Contract Testing.
So let's have a look at the first part of the term "Consumer-Driven Contract Testing". "Consumer-Driven" in this regard means that the API is not dictated by the creator of the API. Usually when it comes to API design, the team that is providing the API is taking care of the design of it. Alternatively in "Consumer-Driven" Contract Testing, the consumer of the API is specifying the API according to its needs. This does not mean that the consumer alone dictates the API. In optimal scenarios, the API specification is the result of an open discussion with having all parties' interests in mind and coming to a solution that works for every party involved. Therefore "Consumer-Driven" just refers to the process of creating an API specification.

What is Pact?

Pact is a code-first tool for testing HTTP and message integrations using contract tests. Contract tests assert that inter-application messages conform to a shared understanding that is documented in a contract.

Taken from the Pact Documentation

In my own words: Pact is a language-agnostic framework implementing Consumer-Driven Contract testing, to verify the behavior and integration of an API by testing all relevant parties in isolation. The API specification is done in a JSON file with its very own schema. We will take a look at such a specification in the next part of this series.

The following image shows how Pact implements Consumer-Driven Contract Testing on a very high level

using Pact to test Consumer and Provider in isolation by spinning up a mock server acting accordingly to the specification

To run Consumer-Driven Contract tests with Pact on the Consumer-side you are going to spin up a mock server that is simulating the behavior of the API Provider. Therefore the Consumer is performing its request as it would be in the normal program flow. If the request is compliant to the specification, the mock-server is going to reply with the specified response. Part of this test is also to verify that the Consumer works as expected with the returned response.

On the Provider-side, this looks pretty similar. In this case, the mock server Pact spins up will simulate the Consumer of the API. Pact is going to perform the request according to the contract and verifying that the server response is according to the specification.

Knowing this makes it clear that both parties are tested in isolation, but by using the same contract you test the API interaction integratively. Using this testing approach gives you high confidence about the integration of your Provider and the Consumer, you get fast feedback, and you can develop the relative part on its own without being dependant on the progress of the relative other party.

Using Consumer-Driven Contract Testing makes sense when:

you are having lots of inter-service communication
microservices
Provider is developed by a different team than the Consumer

Using Consumer-Driven Contract Testing may not make sense when:

providing an API for external parties
consuming third party APIs
Provider already exists and you are reusing the same API

Does Consumer-Driven Contact Testing replace E2E testing?

TL;DR Nope.

Consumer-Driven Contract Testing is a good approach in an overall testing strategy. It does not replace E2E testing as E2E Testing is business-case driven and process-oriented. E2E tests will give you great insights whether your business use cases are working as expected, but Consumer-Driven Contract Testing is solely focused on API integration. The test execution is very fast and wrong assertions can be pinpointed really well, but E2E Tests have a way bigger scope, giving you more clearance on the functionality of your overall application.

Outlook

I hoped you enjoyed reading this introduction, as this is only the first part of a series of blog posts I will be writing about this topic. Upcoming in this series:

Taking a look at the Pact Contract specification
Integrating Pact Consumer tests in an Angular Application
Implementing Pact Provider tests in a NestJS Application
Adding Pact API verification to a CI pipeline

Stay tuned for the next part!

Nobody has to use HostListener

Jan-Niklas Wortmann — Wed, 18 Dec 2019 17:19:16 +0000

Angular's @hostListener is well known within the community. Rather unknown are the problems this might have on runtime performance and general application architecture. In general, there are three main problems with using the hostListener decorator.

Missing composability
Performance issues
Lacks configuration options

Before tackling those two problems more in detail, let's have a look at the example code used to demonstrate the problem.
To do so let's have a look at the following Stackblitz example, particularly the BoxComponent:

Here we see an implemented drag'n'drop feature, using the @hostListener decorator. In total, we registered 3 listeners.

A mousedown event, which we are using to set a property signalling that our drag'n'drop is about to start.
A mousemove event, which calculates the position of the rectangle according to the mouse position.
Finally, we are using the mouseup event to signal that our drag'n'drop has ended.

Do note that we used document as eventTarget. We needed that to handle fast mouse movements which might be out of sync with the position of the rectangle. One will notice that when moving the mouse very fast, that one is out of the rectangle element, which would stop our drag'n'drop.

Problems

Let's have a more in-depth look at the problems listed above.

Missing composability

Taking a look into the code, we will notice that we set the property isClicked to true as soon as the mousedown event happens. We use that property to perform an early return inside of the mousemove event handler to stop this function from execution. This is the only way we can compose those two events, which is quite expensive because this mousemove function is still executed with every mouse movement. In terms of composition, this drag'n'drop feature is fairly straight forward. There are several much more complex event composition scenarios, which become extremely difficult when using the @hostListener decorator.

Performance issues

This problem is mostly the resolution of the missing composability. The problem here is that we register the 3 event listener, mentioned above, for every component instance, even though it's impossible to drag'n'drop multiple rectangles at the same time. Therefore what we should aim for is, that only the mousedown event listener is registered for every component and just when this event happens we register the other events accordingly. Doing all this logic within the event listener function is a lot of work and also decently complex. Additionally, there is currently no way to disable a registers @hostListener function. This is also the reason why the code example above constantly listens to mouse move events, even though they are not relevant if there isn't a rectangle selected before.

Lacks configuration options

Usually, the addEventListener provides an argument for configuration options (the description below is copied from the MDN web docs):

capture: A Boolean indicating that events of this type will be dispatched to the registered listener before being dispatched to any EventTarget beneath it in the DOM tree.
once: A Boolean indicating that the listener should be invoked at most once after being added. If true, the listener would be automatically removed when invoked.
passive: A Boolean which, if true, indicates that the function specified by listener will never call preventDefault(). If a passive listener does call preventDefault(), the user agent will do nothing other than generating a console warning.

One can clearly see that those configuration options are very powerful. For sure, one probably don't need to use them for every case. But especially for heavily event-oriented features this configuration options are key. If we take a look at the offical Angular documentation we will see, that we are not able to specify these configuration parameters, when using the hostListener decorator.

Alternative Approaches

We have two different approaches to tackle the problems described above. Depending on your knowledge some of them are more or less complex. Let's have a look!

Using addEventListener

Theoretically one could register nested event listeners. Therefore we could use the addEventListener function to register the event listeners.

Looking at the code example one will notice that this is fairly complex. Especially because we need to take care of registering and unregistering the nested event listeners. Even if all of the problems described above can be solved with this approach, In my personal opinion, I think that this is a very complex and hard to understand solution.

Using fromEvent

The second alternative approach would be using the RxJS fromEvent operator. RxJS shines when it comes to composition of event-oriented code.

Having a look at this code, one will notice that just looking at the lines of code that this is the smallest approach. I have to admit that one needs to be familiar with RxJS to understand and write such code. It's not really intuitive, but therefore RxJS takes care of registering and unregistering the event listener for us. Additionally, we have many more opportunities regarding composability. That's one of the key benefits of using RxJS when dealing with event-oriented code.

If you want to understand the used operators you can have a look at the following blog posts:

Summary

The @hostListener decorator is handy if we just want to listen to single events and don't rely on any kind of composition. Everything that involves a certain event composition should be implemented by using one of the other approaches listed above. In general, @hostListener lacks features that are necessary when dealing with event composition. It completely misses cancellation options and any kind of composability. Those features are crucial when building heavily event-oriented features.
When you are used to RxJS you should probably use the fromEvent operator to perform any kind of complex event handling. If RxJS is not your preferred technology, maybe using plain old addEventListener might be a viable option for you.

Disclaimer

This blog post aims to elaborate on different approaches to deal with event composition. It never intends to blame or hurt someone who was involved in the design or implementation of the @hostListener feature. I personally appreciate any work that was put into that.

takeWhile, takeUntil, takeWhat?

Jan-Niklas Wortmann — Tue, 30 Jul 2019 14:06:45 +0000

It might be know to you already, that there are situations where you actually want to unsubscribe from your Observables.
There are several ways to do this. In several projects, I stumbled across a mixture of using takeWhile & takeUntil. This raises the question, why are there two of that, which sounds similar and act similarly?

About takeWhile

Well, let's take a look at a quick example. The first code snippet we are looking at is using takeWhile to unsubscribe from an Observable.

In this example I have two different Observables. The first is created using the interval operator. This will emit notifications till the condition passed to takeWhile is falsy. Inside the takeWhile we use a boolean variable describing if the user has already clicked or not. As soon has one clicks somewhere in the screen, we unsubscribe from our interval-Observable. To determine if the user already clicked we used a second Observable created with the fromEvent operator. Additionally we used the tap operator, to log the notifications in the console. We can see that our Observable is unsubscribed as soon as there is no new log coming in.

About takeUntil

From a high-level perspective, the code snippets don't look that different. Instead of having a boolean property, describing the state of our Observable, we now directly used the click-Observable.
We pass this Observable instance to the takeUntil operator and as soon as the user clicks somewhere, our interval-Observable will be unsubscribed from.

The Problem

So all in all both code snippets look similar and behave similar, right? Well, No!
Let's have a look at the marble diagrams describing those operators because this will highlight the difference between those two operators.

takeUntil marble diagram, kindly provided by Michael Hladky

takeWhile marble diagram, kindly provided by Michael Hladky

The problem here is that takeWhile is intended to take an incoming notification and check a specified condition on it, which might lead to an unsubscribe. The important fact is, that takeWhile is triggered by the incoming notification and might unsubscribe afterwards. In contrast takeUntil is triggered by the passed Observable.
That's why takeWhile might cause several issues. So definitely, it needs a new notification to unsubscribe. Imagine having a long-living Observable. You will need one notification more with takeWhile than with takeUntil. Also, this additional notification can initiate multiple processes within your Observable. Imagine having code like this:



longLivingObservable$
  .pipe(
    tap(() => this.startAnimation()),
    switchMap(val => this.makeHttpCall(val)),
    takeWhile(val => this.alive),
  )
  .subscribe();

So what's the issue with this piece of code? Well, our component is already destroyed and due to the needed notification, needed before unsubscribing kicks in, we will start an animation and trigger an HTTP call. This is probably unwanted and just afterwards we will check if we want to unsubscribe from our Observable. Besides the fact that those operations are totally superfluous, it also might break our app or pollute our state.

Additionally, if our Observable doesn't emit an additional value, the takeWhile will never be triggered and therefore our Observable will never be unsubscribed. This can be considered as memory-leak, because our Observable stays subscribed.

Now maybe one might argue: "Well, I could move the takeWhile operator at the very beginning of the observable pipeline!"

That's true, you could do this, and you will save the unneeded operations, which is a good start, but you won't unsubscribe from inner observables. So if the Observable returned by makeHttpCall is a long-living Observable, it will not unsubscribe from that, if the takeWhile is before switchMap in the pipe. By the way, the same goes for takeUntil, so make sure to have the unsubscribe-operator at the very end of your pipe.

The Solution

Don't get me wrong, takeWhile is an amazing operator, but just if you actually use the incoming value to determine, whether you want to unsubscribe or not! Do not depend on "global" state, when using takeWhile.
For those scenarios stick to takeUntil and use a Subject instance to trigger it.

A real-world use case for takeWhile would be a long-polling mechanism. Imagine fetching a resource describing a process. This process can be successfully completed or otherwise ongoing. For sure you just want to continue polling while the process isn't completed yet. The code for such a scenario could look like this.



longPolling$.pipe(takeWhile(process => process.completed)).subscribe(() => handleNotCompleted());

For such a scenario, where we use the incoming will, to determine wether we want to stay subscribed or not, takeWhile is ideal! If we have an external trigger, stick with takeUntil.

Wrap Up

use takeWhile when the incoming value make you want to unsubscribe
use takeUntil when there is an outer event determine that you want to unsubscribe
use both of them as the last operator in your Observable pipeline
- There's a tslint rule for that

Special Thanks

I'm really thankful for all the amazing people helped me writing this blog posts.
This goes out to:

About switchMap and friends

Jan-Niklas Wortmann — Thu, 18 Jul 2019 22:21:07 +0000

RxJS comes with more than 100 different operators. SwitchMap is probably the one that is discussed the most often. It's a very powerful operator, being very useful in many situations, but it's also quite a dangerous one. In this blog article, we will talk about switchMap and also covers the issues it might introduce to your application. Additionally, we will cover the operators having a similar use case. This will make it easier for you, the next time you need to pick one of those.

Before we start talking about the dos and don'ts of using switchMap, let's first summarize the way switchMap is working. SwitchMap is a so-called higher-order operator. Maybe you are already familiar with the concept of higher-order functions because it's quite similar.
In case you aren't, A higher-order function is a function returning another function or accepting a function as a parameter. Think about the Array method map. It takes a function as a parameter which is used to define the transformation of every single item within the array.

A higher-order operator is handling an Observable of Observables. SwitchMap particularly is returning the notifications of an inner Observable.



of('hello world').pipe(
  switchMap(value => {
    return ajax.getJSON('http://my.api.com?search=' + value);
  }),
);

This code example will be used to explain switchMap roughly. We will extend it later on, to take a deeper look at it.

But first things first. SwitchMap takes the values from the outer observable (returned by the of operator) and pass those as a parameter to a function which has to return a new observable. In this particular case, we are using the ajax module of RxJS (for reference you can find some information here). Here we are using the getJSON method to perform a get request and return its response as a new observable.

Technically, we are subscribing to the newly returned observable and passing its value to the next operator in the chain or as usual to the next handler in the subscribe method.

Now you are familiar with the basics of switchMap, we will take a deeper look at it. Don't worry if it may take a while to fully understand switchMap in detail. But if you got it, you will notice, that concatMap, mergeMap, and exhaustMap are quite similar. But first, let's dive deep into switchMap. As promised I extended the
example above and to make it more explorable I created a Blitz for it.
In the index.ts, you will stumble across the following piece of code.



const httpCall$ = ajax.getJSON('https://rickandmortyapi.com/api/character/');
const click$ = fromEvent(document, 'click');

const switchMapExample$ = click$.pipe(
  tap(() => console.log('inside switchMap - click happend')),
  switchMap(() => {
    console.log('inside switchMap - start http request');
    return httpCall$.pipe(tap(val => console.log('inside switchMap - http response ', val)));
  }),
);

Instead of passing one single value to the switchMap function we are now calling switchMap every click (for reference take a look at fromEvent). The fromEvent is used as an example for any kind of input stream. It could also be any other Observable you'd like to.
So as soon as you click somewhere on the page it will immediately log inside switchMap - click happened to the console. Afterwards, switchMapis called. This will also log inside switchMap - start http request immediately. At the end of the function passed to switchMap, we are returning an httpCall$ Observable. This will perform an HTTP request as soon as someone subscribes to it. Additionally, we are using tap again to log the value of the HTTP response.
<>
I already mentioned above, switchMap is passing the value of a source Observable and pass this to a function that needs to return a new Observable. SwitchMap will take care of subscribing to that returned Observable. But now there are two edge cases.

What happens if the Observable returned inside switchMap is a long-living Observable which emits multiple items.
What happens if my source Observable emits faster than the one returned inside switchMap

Both of these problems are visualized in the following marble diagram.
If you are not familiar with the marble diagram syntax, take a look at the Marble Diagram Section.

Please notice that all the following marble diagrams are kindly provided by Michael Hladky.

Let's go through these problems one by one. In case we returned a long-living Observable inside our switchMap function, we will see in the marble diagram, that all notifications are outputted. A very common example for a long-living Observable would be HTTP polling, where we request an API every X seconds and return its response. All those responses would be passed to the next operator in the Observable chain. As you can see in the i2$ Observable, both notifications are passed to the output$ Observable. Now that we know how switchMap handles long-living Observables, the second edge case arises. What happens, when the source Observable emits faster than the newly created Observable.
SwitchMap interrupts the Observable execution as soon as there is a new value coming from the source Observable. If you double-check this with the marble diagram, you will notice that the stream i1$ immediately ends as soon as notification b is coming. Additionally, it will trigger the new Observable i2$ and subscribes to that one.
We already said, that switchMap automatically subscribes to the inner Observable. Additionally, it automatically unsubscribes from it, as soon as there is a new value coming from the source Observable. This means that switchMap also includes a build-in subscription-management mechanism.

You can experience this operator in the linked Stackblitz example. It will trigger an HTTP call after you clicked somewhere. If you click fast enough you will notice that some of the HTTP calls are canceled. You can see that in the network view of the Chrome DevTools. If one of the requests is labeled with canceled, this means, that the Observable, that executed the HTTP call, is unsubscribed from.

Now that we know about switchMap, I'd suggest, let's take a look at the other operators.

Comparing to similars

So now it's time to keep my promise. I already mentioned switchMap is very similar to concatMap, mergeMap & exhaustMap. So what's the difference?

ConcatMap

Let's start with concatMap. ConcatMap also passes notifications of a source observable to an inner observable. It subscribes to that and waits till it completes before it uses the next notification emitted by the source observable. So potentially one could run into memory leaks if the source observable emits endlessly and faster than the inner observable can complete. ConcatMap taking care of the order the inner observables were instantiated. Therefore it is the safest operator of those we cover in this article, from a business perspective. Theoretically you could run into the technical problem of having memory leaks, but still, if you are unsure which operator to choose, I'd recommend taking concatMap. You'll be fine, more or less. So if you are performing HTTP requests inside the concatMap function, you can be sure that one receives the response of the responses before the next notification of the source observable is passed to the inner observable. In the meantime, it buffers those notifications to be ready as soon as the inner observable completes.

Maybe the following marble diagram sums up the behavior of concatMap quite well. Instead of interrupting i1$ as it used to with switchMap, it waits for the completion of i1$ and buffers the notifications in between, like b. After the first stream completes it will start working on the buffered notifications.

You can also explore the behavior of concatMap in the Stackblitz I linked above. You need to copy everything from the operators/concatMap.ts file over to index.ts. The code is pretty much the same as before, just instead that it is now using concatMap. What you will notice if you click furiously somewhere in the window, is that it will make HTTP calls for each click you made, but just one by one. And even more important, it waits for every HTTP call to complete before instantiating the next one.

MergeMap

MergeMap or flatMap (which is just an alias of mergeMap) is quite similar to concatMap, although it doesn't consider the order and it doesn't wait for the completion of one inner observable before subscribing to the next one. If we stick to the HTTP example, theoretically one could run into the situation where multiple HTTP requests are initiated inside the mergeMap function, if it doesn't wait for its completion, one could receive the response of the 2nd instantiated before the first one emits its response.

The following diagram displays the behavior quite well. Notifications of stream i2$ can be passed to the output$ stream, even though i1$ didn't completed yet.

Again you can try out the behavior of mergeMap in the linked Stackblitz.

Do note, that mergeMap is definitely the wrong operator if the order of the notifications is important for you. If you need to process notifications sequentially, use concatMap!

ExhaustMap

Last but not least, exhaustMap. which is quite the opposite of switchMap. While switchMap is unsubscribing from the inner observable as soon as there is an incoming notification from the source observable, exhaustMap ignores those notifications completely, until the inner observable completes. This operator is the perfect match if you fear nervously clicking users crashing your application. But be aware that notifications in between aren't buffered, they are completely ignored. This behavior makes it different from concatMap, which will buffer those notifications.

The following marble diagram demonstrates this very well. Notification 'b' is completely ignored! It waits until i1$ completes. Afterwards, it will be triggered by the next notification from the source observable, which is c in the marble diagram below.

And again, you can play around with the behavior of exhaustMap in the linked Stackblitz. If you will do things like double and triple clicks, you will notice, that those are ignored as long as the HTTP request is ongoing. Afterwards, you can click again to retrigger an HTTP call.

The risks of using switchMap

Now that we know about all those fantastic operators, many of you might already have heard, that there might be some issues using switchMap. Let's figure out what this rumor is all about.

The problem with switchMap is that even though it cancels HTTP requests from a client perspective, the backend anyway "receives" those requests and may perform some actions. The problem with that is, that the backend anyway handles the requests and might perform mutation on the objects. This would result in having a different state on the client side than in the backend. For example, you are performing an account transaction in combination with switchMap. If you are initiating this multiple times, for the client it looks like it just happened once, but the backend receives multiple requests which leads to multiple transactions. And for sure no one wants to transfer money multiple times :D As long as you don't perform any mutation on the object instance on the server side or trigger any additional actions, you are good to go with switchMap. Fetching an object or polling objects is a totally valid use case for switchMap, but be aware of server-side actions or mutations!

Wrap up

switchMap subscribes to the inner Observable with every new notification
it automatically unsubscribes from an old inner Observable
Be cautious when using switchMap
Use concatMap when you are unsure
- consider memory leaks of long-living Observables
use switchMap for fetching/polling/ read-only transactions
be aware of server-side mutations or actions performed

Special Thanks

Many thanks to everyone, who helped me writing this blog article.
Thanks to Todd Motto, Wes Grimes and Brian Troncone for reviewing the article and providing very valuable feedback. Additionally, I want to thank Michael Hladky for providing those marvelous marble diagrams!