I have often seen people struggling when using RxJS. They are frustrated because they try too much at once, do not have proper tests, or have difficulties understanding error messages. How can you do RxJS development effectively and efficiently? I give my view on that in this article. Done right, RxJS development is easy because the library offers a lot of solutions for the usually difficult asynchronous programming.

How to develop RxJS code

Mental modal for RxJS

When working with RxJS it is important to have the right ideas about it. Seeing your code as a collection of streams of values can help. On that value stream, you can apply simple operators. Each stream you are dealing with can start, error out, or complete.

Controlled step-by-step approach with verification

Streams can be complex. That means they can have branches, multiple values arriving at different times, or nested structures. And that is why one has to build them step-by-step and include some verification into the process:

• You can effectively build streams by using TDD (Test-Driven Development)
• Keep Observables as flat as possible (avoid nesting where possible)
• Use Typescript properly to achieve additional safety and add more clarity inside streams
• Understand compiler and error messages when something goes wrong

Use reactive code only when necessary

You do not need to cover everything in RxJS. If something is not asynchronous, RxJS is the wrong choice. Keep your streams small and understandable and implement synchronous parts of your application with the right pattern, i.e. in synchronous code. Asynchronous code is hard enough on its own, despite RxJS.

Example case

Let us illustrate the above considerations in an example. In our demo case, we would like to load a Post entity based on a user action. To load that we also need to pass the user ID which is also offered as Observable. To spice things up, we also would like to load the post’s comments after the post is loaded.

Setup testing properly

The start is a simple test with an implementation you could choose to load the post. I have seen code similar to the following one many times. And I have seen developers struggling with it, being frustrated, and in the end, they blame RxJS.

it('does not work', () => {
    const action$: Observable<LoadPostsAction> = of({ postId: 1 });
    const postService = new PostService();

    action$.pipe(
        map(action => action.postId),
        concatMap((postId) => postService.loadPost(postId)),
    ).subscribe({
        next: result => {
            expect(result).toEqual({id: 1, content: 'content of post 2'});
        },
    });
});

If we run that test, all looks good:

The above code looks perfectly fine at first sight. But it is not! The test is green although the assertion is wrong (“post 2” although we would get “post 1” back in the result). Time for our first tip:

☝ Tip #1: Use TDD when developing RxJS streams and let the test first fail.

This means that in our case we first need a proper test setup. When testing asynchronous code in Jest (and alternatives), we need a callback. This is usually defined as “done” and we are then invoking the done() callback after asserting the outcome.

it('does not work', (done) => {
    const action$: Observable<LoadPostsAction> = of({ postId: 1 });
    const postService = new PostService();

    action$.pipe(
        map(action => action.postId),
        concatMap((postId) => postService.loadPost(postId)),
    ).subscribe({
        next: result => {
            expect(result).toEqual({id: 1, content: 'content of post 2'});
            done();
        },
    });
});

We have a failing test and are good to go and start extending our stream:

Of course, there are other testing approaches, e.g. marbles. But I don’t want to open that topic here. You can read my blog post about different RxJS testing approaches if you are interested. Anyway, we need to be sure that we are testing the right thing and that is why our test should fail first, independent of the testing approach!

Have the right mental model

Before we move on let us spend some time to see how you as a developer can think about RxJS streams. The mental model I propose asks us to think about the values and how they stream through our program. We can illustrate this as follows:

Values are green, source Observables blue (they are not the only Observables), and operators are indicated as rounded rectangles. Arrows show the flow of values.

☝ Tip #2: Remember that Observables are just values over time and those values flow through your program.

Now let us extend the functionality safely.

Keep Observables as flat as possible

Let us now tackle the next step of our functionality and load posts by user. For that, we need to take the current user ID into account. RxJS would allow nesting Observables. What you do then is branching of streams. But besides that, you also make code harder to read and harder to change. So it is not advisable to implement the new functionality like this (switchMap is nested inside concatMap):

action$.pipe(
    map(action => action.postId),
    concatMap((postId) => {
        return user.getCurrentUserId$().pipe(
            switchMap((userId) => postService.loadPost(postId, userId))
        );
    })
).subscribe({
    next: result => {
        expect(result).toEqual({id: 1, content: 'content of post 1'});
        done();
    },
});

The user.getCurrentUserId$() Observable is used inside concatMap. This also means that we need to flatten the Observable of loadPost (more towards that in the next sub-section). A flat and clean structure is easier to handle:

action$.pipe(
    map(action => action.postId),
    withLatestFrom(user.getCurrentUserId$()),
    concatMap((postId) => postService.loadPost(postId, null)),
).subscribe({
    next: result => {
        expect(result).toEqual({id: 1, content: 'content of post 1'});
        done();
    },
});

Whenever the action$ delivers a new value we want to combine it with the latest value of the current user’s ID. You see that we kept the null for userId in the loadPost method. This is because we want to first see what the compiler tells us (to showcase the importance of error messages).

Understand error messages

Error messages around RxJS can be hard to understand in the beginning. The last code example from above delivers the following on the postId parameter inside the loadPost method call:

TS2345: Argument of type '[number, number]' is not assignable to parameter of type 'number'.

The method expects a number but receives [number, number]. We have to understand pipe here. Pipe is accepting operators as UnaryFunctions and forwards the output of one operator to the subsequent one. This passed output is one value, object, or array. Calling withLatestFrom changes the values in the stream and transforms number to [number, number], representing the postId and userId in an array. Long story short, to fix the above TS2345 you have to adapt the code to consider the new input to the operator:

action$.pipe(
    map(action => action.postId),
    withLatestFrom(user.getCurrentUserId$()),
    concatMap(([postId, userId]) => postService.loadPost(postId, userId)),
).subscribe({
    next: result => {
        expect(result).toEqual({id: 1, content: 'content of post 1'});
        done();
    },
});

And please don’t use (postId, userId). Something like this is not a UnaryFunction and is not going to work! This error message was not directly provided by RxJS but often occurs during RxJS development.

Another error message one often encounters is about higher-order Observables. Let us go back to the nested example from above. It is easy to miss the higher-order mapping operator, i.e. switchMap, and just use map in place of it:

action$.pipe(
    map(action => action.postId),
    concatMap((postId) => {
        return user.getCurrentUserId$().pipe(
            map((userId) => postService.loadPost(postId, userId))
        );
    })
).subscribe({
    next: result => {
        expect(result).toEqual({id: 1, content: 'content of post 1'});
        done();
    },
});

All looks good at first sight, but the test signals us:

We are expecting an object with fields like content and id. But what we are getting is not such an Object, but an Observable. Whenever you see this, you should check if you need to flatten another Observable. In our case, switchMap flattens an Observable.

☝ Tip #3: Try to understand each error message. They look cryptic and chaotic at times but are really not that hard to understand once you read them carefully. Go through them from top to bottom and focus on the bottom as the root cause is usually hidden there. During development with RxJS errors can happen and you should not guess, but read, and understand.

Update to our value stream model:

Use types

As soon as values become more complex it can help to use types explicitly. True, the Typescript compiler can still help us and infer some types. Nevertheless specifying them explicitly can make it easier for us developers to understand. Extending by types will change our code to:

action$.pipe(
    map((action: LoadPostAction) => action.postId),
    withLatestFrom(user.getCurrentUserId$()),
    concatMap(([postId, userId]: [number, number]) => postService.loadPost(postId, userId)),
).subscribe({
    next: (result: Post) => {
        expect(result).toEqual({id: 1, content: 'content of post 1'});
        done();
    },
});

This makes extensions safer. For example, if we map the response of the post service to the content only (return string instead of Post), we would immediately notice because we also typed the result in the subscribe’s next handler.
The first one here looks okay to the compiler. Although we are passing string (the type of content) instead of Post.

action$.pipe(
    map((action: LoadPostAction) => action.postId),
    withLatestFrom(user.getCurrentUserId$()),
    concatMap(([postId, userId]: [number, number]) => postService.loadPost(postId, userId)),
    map((response: Post) => response.content),
).subscribe({
    next: (result) => {
        expect(result).toEqual({id: 1, content: 'content of post 1'});
        done();
    },
});

As soon as the next handler does have a type for its parameter, the compiler complains:

If you used RxJS before you probably have seen such error messages already. Important here is to understand that the error message is also considering the nesting. That is why we should always go to the innermost part of the message because that is usually the part the easiest to understand. In this case, “Type ‘string’ is not assignable to type ‘Post'”. You see that TypeScript informs us quite well about the error. We expect a Post, but we are getting something of type string. The DX around error messages could be improved though.

☝ Tip #4: some extra types can help to make your code more robust and understand errors earlier. The compiler is a cheap and fast way to “test”, please use it!

Of course, there are cases where explicit types make no sense and we should really on the type inference instead.

Conclusion

I hope those hints give you a better understanding and you can optimize your approach to RxJS development. Having the right mental model about your stream helps to understand what the operators do and what is happening to the values flowing through your program over time.

The post RxJS Mastery – How to build streams appeared first on Ronnie Schaniel.

How can we implement a robust search input field in JavaScript that triggers HTTP requests to get search results? This is a common problem reoccurring in many web applications. RxJS offers a variety of operators to declaratively define what happens in case of events. A keystroke in an input field is an event. That is why we can nicely define the operations that should be executed (or not) in the case of such events.

Aspects to consider for a search term input

In the most basic form, a keystroke in a search box triggers an HTTP request on what is currently written in the input field, and the result is displayed as it comes back from the server. With that approach, the following problems can occur:

• ⚠ If for every keystroke a request is triggered, too many HTTP requests may be executed and overload our backend systems.
• 😲 As distributed systems have varying response times, the request sequence A, B, and C can result for example in the response sequence B, C, and A. It could mean that the response to the request that was started first arrives last. This would confuse users.
• 🔄 A search term can change in quick succession and theoretically also end up on the same value again. Imagine, “RxJS”, “RxJS pat”, followed by “RxJS”. In such cases, we may not want to execute the search for “RxJS” again because it was just executed some milliseconds ago.
• ✅ Executing a search for any kind of search term, e.g. “R”, might be the wrong choice depending on the context. Starting the search after a certain word length can also here release some pressure from the backend systems and avoid unnecessary output to the user.
• ◝ As asynchronous operations are involved, there might be a requirement to inform the user somehow about ongoing operations.
• ⏳ In some cases the search could take a very long time and we would like to cancel it (automatically or by user interaction).
• 🚫 Especially when working with distributed systems, errors are likely to occur.

We can address the problems above with the following potential solutions:

• ⚠ Only after the user has stopped typing for some time, a request should be triggered. We need some sort of idle time detection after characters are entered.
• 😲 There should only be one running search request at a time. This search request should correspond to what is currently written in the search field.
• 🔄 When the input value doesn’t change compared to the last request, the request should not be executed.
• ✅ The search should only start after at least 3 characters were entered.
• ◝ A loading text should be shown underneath the search box during request execution.
• ⏳ After 7s a search request should be cancelled automatically.
• 🚫 Errors have to be caught and the user informed about them.

These are some of the decisive aspects in the context of such a search field. In the remainder of this article, we are going to tackle them one by one with RxJS.

How does RxJS address those aspects?

Basic setup and imperfect solution

Let us first have a look at the demo case. To nicely demo a search, I’m using the post API of jsonplaceholder. It supports a query parameter to filter by post title. This is perfect for our showcase. The search itself looks like this:

As said, a basic search could look like the code below this paragraph. It just uses the operators fromEvent, mergeMap, and ajax. From the keyup event of the search field, we’re accessing the target’s value. This value is the search term and it is passed as a query parameter to the API request. Ajax executes the API request, while mergeMap makes sure that the higher-order Observable is handled fine (ajax returns an Observable inside an Observable stream and therefore flatting is needed). Finally, in subscribe’s next handler, the response is accessed and put into some output container.

fromEvent(searchField, 'keyup')
    .pipe(
        mergeMap(event => ajax(`${apiUrl}?title_like=${event.target.value}`))
    )
    .subscribe({
        next: (httpEvent) => {
            const responseList = httpEvent.response;
            resultContainer.innerHTML = formatToHtml(responseList);
        }
    });

When typing we see a lot of requests flying through our network tab:

5 requests triggered although I did not type slowly!

To address the limitations, RxJS offers a good palette of operators. And they are easy to understand too! Let us now go through the collected list from above one by one and show how RxJS comes into play.

Only trigger requests after the user has stopped typing for some time

The first operator we are going to use to optimize our solution is debounceTime. This operator only emits after a certain time span has passed without another source emission.

fromEvent(searchField, 'keyup')
    .pipe(
        debounceTime(150),
        mergeMap(event => ajax(`${apiUrl}?title_like=${event.target.value}`))
    )
    .subscribe({
        next: (httpEvent) => {
            const responseList = httpEvent.response;
            resultContainer.innerHTML = formatToHtml(responseList);
        }
    });

A time span of 150 ms is usually a good choice. But this is a trade-off in the end between waiting time and the number of requests. Anyway, it already improves the situation in our network tab:

Have only one running request at a time

As already mentioned above we need a higher-order mapping operator to handle the HTTP request. This is because ajax returns an Observable, but it would also be the case when we are using, e.g., Angular’s http implementation. RxJS offers the following higher-order mapping operators: concatMap, mergeMap, switchMap, and exhaustMap. Their behavior is described in this article.

The switch behavior always considers the newest inner Observable that was started and cancels older ones. This is perfect for our job. If a new input value from the search box arrives, a new inner Observable for the HTTP request is created. As an HTTP request is behind ajax’s Observable, the cancellation of it cancels the HTTP request.

fromEvent(searchField, 'keyup')
    .pipe(
        debounceTime(150),
        switchMap(event => ajax(`${apiUrl}?title_like=${event.target.value}`))
    )
    .subscribe({
        next: (httpEvent) => {
            const responseList = httpEvent.response;
            resultContainer.innerHTML = formatToHtml(responseList);
        }
    });

So, do not be surprised to see canceled HTTP requests in the network tab (here we tried to provoke the situation by throttling the network and setting the “Slow 3G” in Google Chrome):

In some rare cases, another mapping operator might make sense:

• if requests are taking very long and we want them to be fully executed once started while still not overloading the server: exhaustMap. It will only run one request at a time.
• every search should be triggered and executed in sequence because all results are interesting: concatMap.

Do not re-execute a request if the value for it has not changed

RxJS provides distinctUntilChanged that only emits if the new value is different from the last one that made it through. To make that work we need to apply this distinct logic to the search term itself and not the event coming from the input field. Because the event is always going to be distinct. Luckily also here RxJS supports us with pluck and filter. Pluck retrieves the value out of event.target while filter makes sure that only truthy values are arriving, i.e. no undefined is reaching that part of our Observable chain:

fromEvent(searchField, 'keyup')
    .pipe(
        debounceTime(150),
        filter(Boolean),
        pluck('target', 'value'),
        distinctUntilChanged(),
        switchMap(searchTerm => ajax(`${apiUrl}?title_like=${searchTerm}`))
    )
    .subscribe({
        next: (httpEvent) => {
            const responseList = httpEvent.response;
            resultContainer.innerHTML = formatToHtml(responseList);
        }
    });

The pluck also simplified the query parameter’s value and event.target.value is not needed anymore there. Instead of pluck, also map could have been an operator to access the target’s value. But pluck is a nice pick here because no null check is needed when traversing the object tree and we only need a single value.
As we are anyway already thinking about pluck, let us simplify the next handler by plucking the response field from the HTTP response:

fromEvent(searchField, 'keyup')
    .pipe(
        debounceTime(150),
        filter(Boolean),
        pluck('target', 'value'),
        distinctUntilChanged(),
        switchMap(searchTerm => ajax<Post[]>(`${apiUrl}?title_like=${searchTerm}`)),
        pluck('response')
    )
    .subscribe({
        next: (response) => {
            resultContainer.innerHTML = formatToHtml(response);
        }
    });

Only start executing requests after the user has entered at least three characters

We have already seen the filter operator above and it will be used also in this case here. Furthermore, we would like to trim whitespaces because those are normally not interesting for a search. Hence trim is coming into play, combined with RxJS’s map.

fromEvent(searchField, 'keyup')
    .pipe(
        debounceTime(150),
        filter(Boolean),
        pluck('target', 'value'),
        map(value => value.trim()),
        filter(searchTerm => searchTerm.length > 2),
        distinctUntilChanged(),
        switchMap(searchTerm => ajax<Post[]>(`${apiUrl}?title_like=${searchTerm}`)),
        pluck('response')
    )
    .subscribe({
        next: (response) => {
            resultContainer.innerHTML = formatToHtml(response);
        }
    });

Display a loading spinner

Here the debate begins. There exist many approaches to implement a loading spinner. Let us start with the following one:

fromEvent(searchField, 'keyup')
    .pipe(
        debounceTime(150),
        filter(Boolean),
        pluck('target', 'value'),
        map(value => value.trim()),
        filter(searchTerm => searchTerm.length > 2),
        distinctUntilChanged(),
        switchMap(searchTerm => ajax<Post[]>(`${apiUrl}?title_like=${searchTerm}`).pipe(
            startWith({ response: { text: 'Loading...', type: 'LOADING_INDICATOR' }}),
        )),
        pluck('response')
    )
    .subscribe({
        next: (response) => {
            if (response?.type === 'LOADING_INDICATOR') {
                loadingIndicator.style.visibility = 'visible';
            } else {
                loadingIndicator.style.visibility = 'hidden';
                resultContainer.innerHTML = formatToHtml(response);
            }
        }
    });

In that first version, we are piping the Ajax request into startWith. To follow the structure for response we deliver the text Loading… in an object together with the type LOADING_INDICATOR. The pluck works and in the next handler, we can then put the result into the resultContainer and change the visibility of the loading indicator when required. This might be an acceptable solution and it is even fully declarative in the upper part (in the pipe after fromEvent). However, in the next handler, we are going into an imperative mode (anyway due to the resultContainer’s innerHTML handling, but that is usually addressed through frameworks, e.g. async pipe in Angular).

An alternative is to tap BehaviorSubjects from within the Observable chain. This variant is also somewhat imperative. But it gives us a second Observable to control the loading indicator:

const loadingSubject$ = new BehaviorSubject(false);
// some code to subscribe to the loadingSubject$ as Observable 
// and control the visibility of the loading element


tap(_ => loadingSubject$.next(true)),
switchMap(searchTerm => ajax<Post[]>(`${apiUrl}?title_like=${searchTerm}`)),
tap(_ => loadingSubject$.next(false)),

Before and after the switchMap a tap operator is placed to perform the side-effect of telling the BehaviorSubject whether to show something or not.

Both variants have their drawbacks. I’m still looking for a good solution here.

Cancel a request automatically after 7 seconds

Last but not least we need to talk about the not-so-happy cases. Requests can time out or other errors can happen. We would like to inform our users about such cases. Therefore after 7 seconds of no response, an error message should be displayed and the ongoing request be cancelled. Yet another specific operator comes to the rescue. This time it is timeout.

fromEvent(searchField, 'keyup')
    .pipe(
        debounceTime(150),
        filter(Boolean),
        pluck('target', 'value'),
        map(value => value.trim()),
        filter(searchTerm => searchTerm.length > 2),
        distinctUntilChanged(),
        tap(_ => loadingSubject$.next(true)),
        switchMap(searchTerm => ajax<Post[]>(`${apiUrl}?title_like=${searchTerm}`).pipe(
            timeout(REQUEST_TIMEOUT))
        ),
        tap(_ => loadingSubject$.next(false)),
        pluck('response')
    )
    .subscribe({
        next: (response) => {
            resultContainer.innerHTML = formatToHtml(response);
        }
    });

The timeout operator is defined in the pipe after ajax. This is because we want to timeout if the request is too slow and we would like the request to be canceled in such cases. As a consequence, we can see the following in our browser when the response does not arrive in time (REQUEST_TIMEOUT is the timeout in milliseconds).

Let us optimize that in the next section where we catch uncaught things.

Show an error message when the search request fails

If we would like to catch any errors, you might have already guessed the operator for that. We apply catchError:

fromEvent(searchField, 'keyup')
    .pipe(
        debounceTime(150),
        filter(Boolean),
        pluck('target', 'value'),
        map(value => value.trim()),
        filter(searchTerm => searchTerm.length > 2),
        distinctUntilChanged(),
        tap(_ => loadingSubject$.next(true)),
        switchMap(searchTerm => ajax<Post[]>(`${apiUrl}?title_like=${searchTerm}`).pipe(
            timeout(REQUEST_TIMEOUT))
        ),
        tap(_ => loadingSubject$.next(false)),
        pluck('response'),
        catchError(error => {
            loadingSubject$.next(false);
            displayError(error.message);
            return [];
        }),
    )
    .subscribe({
        next: (response) => {
            resultContainer.innerHTML = formatToHtml(response);
        }
    });

The nice thing about the catch is that we can place it at the end and it will handle any error that happens in the stream. The default value empty array is returned. With a little bit of CSS and HTML, it looks like in the image below. The error is shown while the loading indicator is hidden again.

Conclusion

In the course of this article, we have used 10 different operators. And I could even think of some more to apply in that context, e.g. retry or finalize. This is probably where some people start to complain about how hard to learn RxJS is. But, please keep in mind that every operator is designed for its purpose and does its specific task well! This allows us to combine different operators as we wish, to specify the behavior of our program from simple building blocks. The nice thing about all that: you can declaratively program and define what should happen.

Please note, that the TypeScript usage in these examples was not ideal. More type safety should be added. But the focus here was on RxJS. If someone has a good approach for the loading indicator, let me know!

This post is part of the RxJS mastery series. As always the code examples can be found on GitHub.

The post RxJS Mastery – RxJS Patterns: a robust HTTP-based search input appeared first on Ronnie Schaniel.

RxJS provides some handy utility operators. Count, max, min, and reduce are the ones we have a look at in this article.

RxJS count returns the number of values

The RxJS count operator emits the number of values once the source completes. Below the source emits the values a, b, and c. This is why count is returning 3 at the 4th timeframe (together with the completion).

const result$ = cold('abc|').pipe(
    count()
);

expectObservable(result$).toBe(
    '---(d|)', { d: 3 }
);

The operator also works with a condition. This gives us the possibility to count the values matching a predicate. In the below example, we are counting the numbers greater than 2.

const result$ = cold<number>('1234|').pipe(
    count(v => v > 2)
);

expectObservable(result$).toBe(
    '----(d|)', { d: 2 }
);

RxJS max and min

Also for the RxJS max and min operators the completion time of the source Observable is decisive. Because only at that time all values are known and, as the name suggests, the maximal or minimal value is emitted.

const result$ = cold<number>('8923402|').pipe(
    max()
);

expectObservable(result$).toBe(
    '-------(r|)', { r: '9' }
);

Similarly, the number 0 is found when applying min:

const result$ = cold<number>('8923402|').pipe(
    min()
);

expectObservable(result$).toBe(
    '-------(r|)', { r: '0' }
);

The operator works by default with numbers but also accepts a comparator function to compare objects. Let us try to find the cheapest product:

type product = { name: string, price: number }
const result$ = cold<product>('abc|',
    {
        a: { name: 'Book', price: 10 },
        b: { name: 'Video', price: 15 },
        c: { name: 'Course', price: 20 },
    }).pipe(
    min((a, b) => a.price < b.price ? -1 : 1)
);

expectObservable(result$).toBe(
    '---(r|)', { r: { name: 'Book', price: 10 } }
);

The cheapest one is the Book with a price of 10.

RxJS reduce

Most of you probably know the reduce function typically available in most languages. Reduce applies an accumulator function on each value which allows to combining past values with new ones. Optionally a seed can be specified as a starting value.
In our example, we simply sum up numbers and start with a seed value of 0:

const result$ = cold<number>('8923402|').pipe(
    reduce((a, b) => Number(a) + Number(b), 0)
);

expectObservable(result$).toBe(
    '-------(r|)', { r: 28 }
);

As with every operator in this article, the emission happens once the source completes.

Exercise for the RxJS mathematical and aggregator operators 💪

Build RxJS reduce by combining the scan operator with the last operator.

This post is part of the RxJS mastery series. As always the code examples can be found on GitHub.

The post RxJS Mastery – #71 Mathematical and Aggregator Operators appeared first on Ronnie Schaniel.

RxJS offers a variety of conditional and boolean operators. Let us have a look at defaultIfEmpty, every, find, findIndex, and isEmpty.

RxJS defaultIfEmpty for default values

Observables wrap asynchronous operations that might not be 100% reliable. This means they sometimes either do not deliver a value or do not return it in time. In the best case, it is just a missing value, in the worst the Observables chain requires a value or would through an error otherwise. That is where defaultIfEmpty comes to the rescue.
If the Observable completes without emitting any next value, defaultIfEmpty delivers a specified value.

const result$ = cold('---|').pipe(
    defaultIfEmpty(0)
);

expectObservable(result$).toBe(
    '---(d|)',
    {
        d: 0,
    }
);

Of course, the default value can only be delivered on the 4th time frame when the original Observable has completed.

RxJS every to check the whole sequence

The RxJS every operator checks all the values that are emitted. If one value violates the condition specified, false is emitted and the Observable completes. If all values pass, true is emitted with completing.

const result$ = cold<number>('24678|').pipe(
    every(v => v % 2 === 0)
);

expectObservable(result$).toBe(
    '---(f|)',
    {
        f: false,
    }
);

In the below example, all values return true for the condition:

const result$ = cold<number>('2468|').pipe(
    every(v => v % 2 === 0)
);

expectObservable(result$).toBe(
    '----(t|)',
    {
        t: true,
    }
);

RxJS find to emit a single value matching a condition

Find checks every value in the stream and emits the first one for which the specified condition is true. At the same time, it sends a complete notification. The condition in the below example is checking for multiples of 3. In the sequence of numbers from 1 to 9, the first value that fulfills the condition is 3. Hence, 3 is emitted and the stream completes.

const result$ = cold<number>('123456789|').pipe(
    find(v => v % 3 === 0)
);

expectObservable(result$).toBe(
    '--(v|)', { v: "3" }
);

If no value fulfills the condition and the source completes, undefined is emitted. In the below test, we are trying to find an even number in a sequence of odd numbers:

const result$ = cold<number>('1357|').pipe(
    find(v => v % 2 === 0)
);

expectObservable(result$).toBe(
    '----(u|)', { u: undefined }
);

RxJS findIndex for finding the index

The findIndex operator works like find, but emits only the index of the first found value. So, if we’re taking the above example of the previous section, the index 2 is emitted and not the value 3:

const result$ = cold<number>('123456789|').pipe(
    findIndex(v => v % 3 === 0)
);

expectObservable(result$).toBe(
    '--(i|)', { i: 2 }
);

Please note that the case where no value is found does not end up with undefined. The value -1 is emitted instead, following the logic of javascript’s findIndex.

const result$ = cold<number>('1357|').pipe(
    findIndex(v => v % 2 === 0)
);

expectObservable(result$).toBe(
    '----(i|)', { i: -1 }
);

RxJS isEmpty emits true if the source is not emitting any values

The final operator that we are looking into in the area of conditional and boolean operators, is the isEmpty operator. As the name suggests, it checks the source for any values. If no values are emitted by the source, the value true is emitted and the Observable completes.

const result$ = cold<number>('----|').pipe(
    isEmpty()
);

expectObservable(result$).toBe(
    '----(t|)', { t: true }
);

Once a value is found, the stream completes and emits false:

const result$ = cold<number>('---123|').pipe(
    isEmpty()
);

expectObservable(result$).toBe(
    '---(f|)', { f: false }
);

Exercise for the RxJS conditional and boolean operators 💪

Prevent the EmptyError in the below Observable chain. Deliver the value 0 instead.

const result$ = cold('---|').pipe(
    first(),
);

expectObservable(result$).toBe(
    '---(d|)',
    {
        d: 0,
    }
);

This post is part of the RxJS mastery series. As always the code examples can be found on GitHub.

The post RxJS Mastery – #70 Conditional and Boolean Operators appeared first on Ronnie Schaniel.

People often complain that it can be hard to use RxJS in the right way. There is a feeling that memory leaks are always around the corner. With the recent introduction of Signals in Angular the RxJS situation is even more unsure. However, RxJS is here to stay! To avoid RxJS pitfalls, understanding the concepts is crucial. Besides that there is also some help we can get in through RxJS eslint. In this post, I show various rules.

Setup of RxJS with eslint

There is an eslint-plugin-rxjs available. To install the package you first need to install the ESLint TypeScript parser followed by the package itself:

npm install @typescript-eslint/parser --save-dev
npm install eslint-plugin-rxjs --save-dev

In the .eslintrc.js file in your project you can configure the plugin (code taken from https://github.com/cartant/eslint-plugin-rxjs):

const { join } = require("path");

module.exports = {
  parser: "@typescript-eslint/parser",
  parserOptions: {
    ecmaVersion: 2019,
    project: join(__dirname, "./tsconfig.json"),
    sourceType: "module"
  },
  plugins: ["rxjs"],
  extends: [],
  rules: {
    "rxjs/no-async-subscribe": "error",
    "rxjs/no-ignored-observable": "error",
    "rxjs/no-ignored-subscription": "error",
    "rxjs/no-nested-subscribe": "error",
    "rxjs/no-unbound-methods": "error",
    "rxjs/throw-error": "error"
  }
};

Alternatively, the recommended configuration can be used. This enables some of the rules that are likely to be relevant for most usages.

const { join } = require("path");

module.exports = {
  parser: "@typescript-eslint/parser",
  parserOptions: {
    ecmaVersion: 2019,
    project: join(__dirname, "./tsconfig.json"),
    sourceType: "module"
  },
  extends: ["plugin:rxjs/recommended"],
};

For Angular projects, there is another plugin (eslint-plugin-rxjs-angular) available.

ESLint in action

We are creating a task in the package.json to execute eslint for our project. Here we are only interested in a certain directory.

"lint": "npx eslint src/rxjs_eslint/**/*.ts"

This allows us to run the lint functionality and see the violations. If we would have a file like the following:

import { of } from 'rxjs';


// finnish notation violation
const obs = of(1);

// correct example
const finnish$ = of(1);

The rule "rxjs/finnish": "error" sees an error and shows us the file and line where we violate the rule:

Deep dive into some rules

A full list of rules is available on the official GitHub page of the plugin. Nevertheless, I want to show some interesting ones in detail and explain which situations we can avoid thanks to them.

No nested subscribe

A subscribe within a subscribe is bad practice. It breaks the stream and can lead to memory leaks. It is also kind of imperative instead of the declarative way that RxJS nicely provides for us. Luckily eslint-plugin-rxjs offers a rule:

"rxjs/no-nested-subscribe": "error"

Like that, we would receive a reminder if a nested subscription appears in our code:

of(1).subscribe({
    next: value => {
        of(2).pipe(
            map(inner => inner + value)
        ).subscribe(console.log)
    }
});

Usually, we can handle such a situation by just pulling the operators up and flattening the higher-order Observable:

of(1).pipe(
    concatMap(value => of(2)
        .pipe(
            map(inner => inner + value))
    )
).subscribe(console.log);

Of course, also other higher-order Observable mapping operators than concatMap can be used.

No ignored subscription

When we subscribe in RxJS, we should also unsubscribe to stop the async operation or clean up. To unsubscribe we need at least to assign the subscription somewhere or use an operator like take that unsubscribes.

RxJS eslint offers the “no-ignored-subscription” rule that fires if a subscription is neither assigned to a variable or property nor passed to a function. The following code would violate the rule:

interval(1e3).pipe().subscribe(
    (value) => console.log(value)
);

However, also using a take operator will still fire the rule. This is kind of okay because we don’t know whether the Observable will emit any value and ever reach the take operator the required times.

interval(1e3).pipe(take(1)).subscribe(
    (value) => console.log(value)
);

Hence, it is better in my opinion to use the “no-ignored-subscription” just as a warning and not fail the linting completely. This can be configured in the .eslintrc.js file:

"rxjs/no-ignored-subscription": "warn"

No internal

The “no-internal” rule is again more obvious and straightforward. We do not want to rely on internals:

import { of } from 'rxjs/internal/observable/of';

import { of } from 'rxjs';

This results in an error because of the import on line 1.

1:20  error  RxJS imports from internal are forbidden  rxjs/no-internal

Preferable is the import on line 3.

Conclusion

Especially in larger code bases, linting is going to help ensure consistency. As always with rules a discussion should happen about which ones to use. Explaining which problems a certain rule is preventing, can help to get it in.

This post is part of the RxJS mastery series. As always you can find the code examples on GitHub.

The post RxJS Mastery – More safety for RxJS through eslint appeared first on Ronnie Schaniel.

There are many options out there when testing reactive code based on RxJS. Hence, especially for beginners, it can be hard to choose between all the RxJS testing approaches. This leads to frustration and in the worst case, the code remains untested. In this article, I want to show different patterns and their problems.

Please note, that the mentioned code is reduced to the minimum to bring the necessary points across. The full tests can be found on GitHub. Also, we are only scratching the surface of various testing approaches and mainly checking setup and verification.

After the introduction of an example code to be tested you will see:

1. Mocking with the of operator and subscribing explicitly
2. Using BehaviorSubject for mocking
3. RxJS marbles for mocks and outcomes
4. Auto-spies for setup and observer-spy to verify values

Example: combining asynchronous resources on an action

Sometimes you need to load something from an HTTP service and based on the result you retrieve something related to that. Finally, everything should be emitted together. The resources to load are based on values emitted by an Observable. And to make it even more reactive the trigger to load things is also an Observable emitting a value. This is going to be the scenario for our tests.

For our example, you can think of a “Load more” button on a feed that loads more posts and their associated comments. An action is triggered to load posts followed by their comments. The action itself tells us which posts to load. So, the code may look like the following:

loadPostAction$.pipe(
    map(action => action.postIds),
    concatMap((postIds: number[]) =>
        from(postIds).pipe(
            mergeMap(postId => postService.loadPost(postId)),
        ),
    ),
    mergeMap(post => commentService.loadComments(post.id).pipe(
        map(comments => ({ ...post, comments: comments }))
    )),
);

ⓘ Some explanations:

• loadPostAction$ is an Observable emitting an action that contains the IDs of those posts that we want to load.
• loadPost of the postService is a method to call an HTTP service that returns a single post. It accepts a post ID as input.
• The commentService offers a method loadComments. It accepts a post ID and returns an array of comments as Observable for that post.

For testing, we set up some basic mocks. The content of the post is going to contain “content of post” followed by the post ID. For the comments, we want to return an array of two comments mentioning a static text alongside the post ID. If we run the above code in the test context, we expect something like the below output:

{
  id: 5,
  content: 'content of post 5',
  comments: [ 'first comment (5)', 'another comment (5)' ]
}

{
  id: 6,
  content: 'content of post 6',
  comments: [ 'first comment (6)', 'another comment (6)' ]
}

{
  id: 7,
  content: 'content of post 7',
  comments: [ 'first comment (7)', 'another comment (7)' ]
}

For each post, the comments are loaded and assigned to the Post object. There are better ways to implement the above functionality. And one would maybe structure the code differently. However, it is sufficient as an example for us. We are ready to go and explore the first option for testing.

1. Mocking with the of operator and subscribing explicitly

Our code is based on Observables. Wouldn’t it be great, to just use the RxJS of operator to set those Observable values? Let’s try.

We define the loadPostAction$, loadPost and loadComments as follows:

const loadPostAction$: Observable<LoadPostsAction> = of({ postIds: [5,6,7] });
const loadPostMock = jest.spyOn(postService, 'loadPost');
const loadCommentsMock = jest.spyOn(commentService, 'loadComments');

loadPostMock.mockImplementation((postId: number): Observable<Post> => of(
    {id: postId, content: `content of post ${postId}` }
));
loadCommentsMock.mockImplementation((postId: number): Observable<string[]> => of(
    [
        `first comment (${postId})`,
        `another comment (${postId})`
    ]
));

The action is an Observable based on of, while the two service methods are mocked with the help of jest. In the end also they are based on the of operator. Now we can assign the loadPostAction$.pipe... to a result$ Observable, explicitly subscribe, push the values into an output array, and verify:

// const result$ = loadPostAction$.pipe( ...
//    map... etc.

const output: Post[] = [];

result$.subscribe({
    next: post => output.push(post),
});

expect(output).toEqual(expectedPosts);

Testing with of and subscribe is more or less straightforward. However, it has the following disadvantages:

• ⏱ There is no notion of time to specify easily at what exact moment values are emitted. Similarly, it is harder to assert when values arrive in the final result Observable.
• ⏳ Sometimes time-based Observables, like interval, are used in the code under test. In this case, the run time of the test is most likely going to be longer than just a few milliseconds.
• ✍ Generally setting up subscribe and pushing results to an array (if necessary) can be tedious. If you want to test error and complete notifications, it is even more work.
• ❗Subscribing might also cause memory leaks in some cases.

On to the next section where the setup part is modified slightly.

2. Using BehaviorSubject for mocking

In Section 1 the Observables were defined using the of operator that emits synchronously:

const loadPostAction$: Observable<LoadPostsAction> = of({ postIds: [5,6,7] });

This is not very convenient when you want to see different values separated by time emitted during a single test. This is where BehaviorSubject comes into play. As you probably know, a Subject in RxJS is an Observable and an Observer at the same time. Therefore it offers a next method to push some values.

const loadPostAction$: BehaviorSubject<LoadPostsAction> = new BehaviorSubject({ postIds: [5,6,7] });

Thanks to the Subject, we can test how the code behaves after the loadPostAction is triggered with some new post IDs.

// still subscribing to result$ and pushing to an output array 

// just pushing some new values
loadPostAction$.next({ postIds: [8,9,10] });

expect(output[3].id).toEqual(8);
expect(output[4].id).toEqual(9);
expect(output[5].id).toEqual(10);

After having loaded the posts with IDs 5, 6, and 7, we are interested in the three next posts (8, 9, and 10). To keep things simple, the assertion here is done on the id field. This variant with BehaviorSubject works too, but it still feels a bit awkward:

• ✓ We can push different values for an involved Observable.
• ⏱ There is still no notion of time (which might be ok for simple tests).
• 📏 The verification phase wasn’t changed at all and still involves subscribing explicitly and checking the content of an array.

3. RxJS marbles for mocks and outcomes

RxJS offers marble testing. To apply it, one has to first understand the marble syntax. Through the helper methods, hot and cold Observables can be created that follow a certain timing.

const loadPostAction$: Observable<LoadPostsAction> = hot('-a-----b-------|', {
    a: { postIds: [5,6,7] },
    b: { postIds: [8,9,10] },
});
const loadPostMock = jest.spyOn(postService, 'loadPost');
const loadCommentsMock = jest.spyOn(commentService, 'loadComments');

loadPostMock.mockImplementation((postId: number): Observable<Post> => cold('-r|', {
    r: {id: postId, content: `content of post ${postId}`}
}));
loadCommentsMock.mockImplementation((postId: number): Observable<string[]> => cold('--r|', {
    r: [
        `first comment (${postId})`,
        `another comment (${postId})`
    ]
}));

ⓘ Some notes to the above setup:

• loadPostAction$ was defined as a hot Observable. Already there we are defining the emissions over time (IDs 8, 9, 10 coming 6 time frames after the first batch of IDs).
• For the service’s methods, we again spy on the service classes and mock the implementation. Here the return values are based on cold Observables involving one or two frames of waiting time respectively.

Also for the verification step, marbles offer us a convenient method expectObservable. It lets us define the expected output also as a marble diagram, i.e. as a string with time frames and emitted values.

expectObservable(result$).toBe('----(abc)-(def)|', {
    a: {
        id: 5,
        content: 'content of post 5',
        comments: [ 'first comment (5)', 'another comment (5)' ]
    },
    ...

On frame 4 the first post with ID 5 arrives in the output together with two other posts (ID 6 and 7). On frame 10 the next group of 3 are emitted. Please note that parentheses also move the time forward. Finally, the | sign denotes completion. This is really cool if we want to test the exact timing. For our example though it wouldn’t matter that much. We are just interested in receiving posts.

Let us pin down the most important points for marble testing

• ⏱ Marbles testing is a good choice if the timing of the Observables is important.
• 😃 Setup and verification can both be done in a similar way.
• ✓ It not only allows testing the next notification but also testing errors and especially completion is rather easy.
• ✍ Sometimes it can be tedious to find the exact time span for the result verification. You find yourself adjusting frame by frame.
• 😤 Especially the time progression due to the parentheses is annoying and can prevent testing certain scenarios.
• 🙄 The setup in the tests can be a bit tedious, especially when using the plain test scheduler. There are libraries though for jest and jasmine.

4. Auto-spies for setup and observer-spy to verify values

For some devs, the marbles syntax is hard to get or the timing of emissions is not important for the code under test. In that case, observer-spy might be a better choice for testing RxJS. It usually is combined with auto-spies to set up the input Observables.

let loadPostActionSpy$ = createObservableWithValues(
    [
        { value: { postIds: [5,6,7] } },
        { value: { postIds: [8,9,10] }, delay: 1000 },
        { complete: true },
    ],
    { returnSubject: true }
);
const loadPostAction$ = loadPostActionSpy$.values$;

const postServiceSpy = createSpyFromClass(PostService);
const commentServiceSpy = createSpyFromClass(CommentService);

postServiceSpy.loadPost.mockImplementation((postId: number): Observable<Post> => of(
    {id: postId, content: `content of post ${postId}` }
));
commentServiceSpy.loadComments.mockImplementation((postId: number): Observable<string[]> => of(
    [
        `first comment (${postId})`,
        `another comment (${postId})`
    ]
));

ⓘ Let us see what is going on in the above code:

• loadPostAction$ is defined with the help of the method createObservableWithValues. This lets us define various emissions and the completion (without marble diagrams 😉)
• The createSpyFromClass method of jest-auto-spies is used to mock the implementation.

The verification part of the test looks pretty neat as you are going to see below. By using subscribeSpyTo we can create an observerSpy that lets us continuously check the values. Various methods are available (see docs) to test, e.g., all values, just the last ones, or the completion.

const observerSpy = subscribeSpyTo(result$);

// some intermediate verification for posts 5,6,7
expect(observerSpy.getValues()).toEqual(expectedPosts);

await observerSpy.onComplete();

expect(observerSpy.getLastValue()?.id).toEqual(10);
expect(observerSpy.receivedComplete()).toBe(true);

Let us also list the most important characteristics of this RxJS testing approach:

• ✍ Auto-spies combined with observer-spy offer similar capabilities to rxjs-marbles without the need to define the marble diagrams.
• ⏱ Some timing can be defined (see createObservableWithValues).
• ✅ Verification does not involve any nesting or additional data structures.
• 😊 Checking values feels reasonable. We can access and check the parts we are interested in.

Summary

As so often in web development, we have many different approaches available. Choosing the right one from the RxJS testing approaches depends on many factors. Is the timing of the Observables important for the code under test? Do we only care about the values and the order in which they appear in the output? Especially in larger code bases it is beneficial to choose one approach and stick with it. Otherwise, the code base is not consistent which further confuses developers.

This post is part of the RxJS mastery series. As always you can find the code examples on GitHub.

The post RxJS Mastery – Testing approaches compared appeared first on Ronnie Schaniel.

RxJS toArray is another utility operator. It emits all the source values as an array once the source completes.

RxJS toArray only works on Observables that complete

As the toArray operator needs to collect all next notifications, it needs to know when the Observable has completed. Only then we can be sure to have caught all values. This also has impact on the timing of the emission of course.

const result$ = cold('abcd|').pipe(
    toArray()
);

expectObservable(result$).toBe(
    '----(r|)',
    {
        r: ['a', 'b', 'c', 'd'],
    }
);

In the above example, the values a, b, c, d are emitted followed by a complete notification. Logically the result$ is emitting once at the time the source has completed.

Exercise for the RxJS toArray operator 💪

Collect 3 values each and emit them as an array repeatedly. You might want to look into the repeat and delay operators.

const result$ = interval(1).pipe(
    // a combination of toArray, take, delay and repeat
);

expectObservable(result$).toBe(
    '----w---x---y---(z|)',
    {
        w: [0, 1, 2],
        x: [0, 1, 2],
        y: [0, 1, 2],
        z: [0, 1, 2],
    }
);

This post is part of the RxJS mastery series. As always the code examples can be found on GitHub.

The post RxJS Mastery – #69 toArray appeared first on Ronnie Schaniel.

RxJS offers some time operators in the utility category. In this article, we are going to have a look at timeInterval, timestamp, timeout, and timeoutWith.

RxJS timeInterval measures the time between two values

The timeInterval operator emits an object containing not only a value but also the time that has passed since emitting the previous value. The easiest example is probably the one based on interval.

interval(1000)
    .pipe(take(4), timeInterval())
    .subscribe({ next: x => console.log(x), complete: done});

// TimeInterval { value: 0, interval: 1004 }
// TimeInterval { value: 1, interval: 1047 }
// TimeInterval { value: 2, interval: 1010 }
// TimeInterval { value: 3, interval: 1006 }

Be aware that intervals are non-deterministic and it is not always going to be a 1000 ms. Also with rxjs marbles, we can nicely show the behavior. You might notice that the complete notification is not considered:

const timeMeasured$ = cold('100ms a 200ms b 300ms c 400ms |').pipe(
    timeInterval(),
    map((v: TimeInterval<string>) => v.interval),
);

expectObservable(timeMeasured$).toBe(
    '100ms a 200ms b 300ms c 400ms |',
    {
        a: 100,
        b: 201,
        c: 301,
    }
);

Also, the emission itself takes 1 ms. Therefore the time between is 201 ms or 301 ms.

RxJS timestamp attaches the datetime to an emission

The timestamp operator simply creates the current date, usually with Date.now(), and attaches it to the emission. The value emission therefore looks like this: {value: T, timestamp: R}.

interval(1000)
    .pipe(take(4), timestamp())
    .subscribe({ next: x => console.log(x), complete: done});

// { value: 1, timestamp: 1702807174323 }
// { value: 2, timestamp: 1702807175327 }
// { value: 3, timestamp: 1702807176335 }

You see in the output the value alongside the UNIX timestamp. Again we can have a look at the situation when using the TestScheduler and marbles:

createTestScheduler().run((helpers) => {
    const { expectObservable, cold } = helpers;

    const timeStamped$ = cold('100ms a 200ms b 300ms c 400ms |').pipe(
        timestamp(),
    );

    expectObservable(timeStamped$).toBe(
        '100ms a 200ms b 300ms c 400ms |',
        {
            a: { value: 'a', timestamp: 100 },
            b: { value: 'b', timestamp: 301 },
            c: { value: 'c', timestamp: 602 },
        }
    );
});

Thanks to the TestScheduler the time is not based on the AsyncScheduler’s Date.now(). Time starts at 0 and adds up nicely.

RxJS timeout errors if values do not arrive in time

The timeout operator allows to throw an error should too much time pass until a value is emitted. In the below example, we specify a timeout of 250 ms. Therefore the value c has no chance of being emitted 300ms after the value b. Instead, a TimeoutError is thrown.

const timeout$ = cold('100ms a 200ms b 300ms c 400ms |').pipe(
    timeout(250),
);

expectObservable(timeout$).toBe(
    '100ms a 200ms b 249ms #',
    {
        a: 'a',
        b: 'b',
    },
    new TimeoutError(),
);

The timeoutWith operator is deprecated and the timeout operator itself offers a with parameter in the TimeoutConfig. This helps us to specify how we want to time out. We can for example define a custom error instead of the TimeoutError.

class CustomTimeoutError extends Error {
    constructor() {
        super('It was too slow');
        this.name = 'CustomTimeoutError';
    }
}

createTestScheduler().run((helpers) => {
    const { expectObservable, cold } = helpers;

    const timeout$ = cold('100ms a 200ms b 300ms c 400ms |').pipe(
        timeout({
            each: 250,
            with: () => throwError(() => new CustomTimeoutError())
        }),
    );

    expectObservable(timeout$).toBe(
        '100ms a 200ms b 249ms #',
        {
            a: 'a',
            b: 'b',
        },
        new CustomTimeoutError(),
    );
});

Note that we have to pass a TimeoutConfig object in this case where the timeout value is defined in the each parameter.

Exercise for the RxJS timeout operator 💪

The timeout operator not only allows to specify a custom error in the with parameter. But it also enables us to switch to a different Observable entirely. That way we can switch to a faster Observable on timeout. This is exactly the task for you. When the timeout occurs you should replace the Observable with something that fulfills the below marbles diagram:

const timeout$ = cold('100ms a 200ms b 300ms c 400ms |').pipe(
    timeout({
        each: 250,
        with: // your code
    }),
);

expectObservable(timeout$).toBe(
    '100ms a 200ms b 249ms c 100ms |',
    {
        a: 'a',
        b: 'b',
        c: 'c'
    },
);

This post is part of the RxJS mastery series. As always the code examples can be found on GitHub.

The post RxJS Mastery – #68 timeInterval, timestamp, timeout appeared first on Ronnie Schaniel.

The RxJS subscribeOn operator returns the source Observable in a modified state such that the subscription happens with a specified scheduler.

RxJS subscribeOn to customize the emission of values

As schedulers control the speed and order of emissions, this can help to customize an existing Observable to one’s needs. Let us see that in action. The of operator synchronously emits values. We can change that by specifying the asyncScheduler with the help of subscribeOn.

const a$ = of(1, 2, 3).pipe(subscribeOn(asyncScheduler));
const b$ = of(4, 5, 6);

merge(a$, b$).subscribe(console.log);

The output of the above code does not start with 1, 2, 3. But it looks like the following:

4
5
6
1
2
3

Because the values of b$ are emitted synchronously they come first. On the other hand, the values of a$ are put onto the event loop of JavaScript and therefore appear asynchronously.

This post is part of the RxJS mastery series. As always the code examples can be found on GitHub.

The post RxJS Mastery – #67 subscribeOn appeared first on Ronnie Schaniel.

The RxJS observeOn operator remits all notifications from the source using a specified scheduler.

RxJS observeOn with animationScheduler for smooth animations

If the scheduler of the source Observable cannot be adapted, the observeOn operator comes into play. The primary use case for the RxJS observeOn operator is the specification of the animationScheduler for certain Observables.

const progressBarDiv = new HTMLDivElement();

interval(10)
    .pipe(observeOn(animationFrameScheduler))
    .subscribe(newHeight => {
        progressBarDiv.style.height = newHeight + 'px';
    });

This helps to get rid of choppy animations because the value emission is better synchronized with the rendering behavior of the browser:

Prefer the delay operator over the delay parameter of observeOn

In addition to the scheduler parameter, observeOn would also support a delay. This delay is applied to every source notification, including errors.

observeOn<T>(scheduler: SchedulerLike, delay: number = 0): MonoTypeOperatorFunction<T>

This is the main reason why the delay operator is recommended over the delay parameter of observeOn. Usually, you do not want to delay errors. Besides the delay operator is also better understood.

This post is part of the RxJS mastery series. As always the code examples can be found on GitHub.

The post RxJS Mastery – #66 observeOn appeared first on Ronnie Schaniel.