The most useful operators and techniques in RxJS Patterns

The most useful operators and techniques in RxJS Patterns

In this article, I want to share the most useful operators and techniques that help avoid unnecessary and repeated computations that in turn will make your app faster and more efficient, and all we need is some RxJS magic.

RxJS is a library that helps make it easier to compose asynchronous or callback-based code, as described on its home page.

But did you know that RxJS could also help to make your applications more efficient and performant thanks to its powerful operators?

Filtering

Filtering operators allow us to filter events from the stream that we want to disregard and avoid sending them to the observable’s subscribers. If we filter the events soon enough in the pipeline, we avoid passing them down to other operators and to the subscription callback.

Of course, this is especially important if the pipeline is doing heavy-computations or HTTP requests.

These operators are primarily used for logic rather than performance reasons, although they’re still useful to avoid computing needless tasks.

The questions you can ask yourself when writing a stream is: should I pass all items through or can I skip them at some point in the pipeline?

filter

The simplest operator to avoid needless computation (among other things) is filter.

If you are already familiar with the method Array.prototype.filter, then you’ll probably know its usage already: we pass a predicate as a parameter to the operator, and if it returns true for the event being streamed, the event will be passed through the pipeline, otherwise, it will be discarded.

const numbers$ = of(1, 2, 3, 4, 5);

const predicate = (n) => n <= 2;numbers$

    .pipe(

        filter(predicate)

     )

    .subscribe(console.log);

// will log 1,2

distinctUntilChanged

Another type of filtering operator is distinctUntilChanged.

This operator will compare the current value with the previous value of the source Observable, and if these are different, it will then pass the item through. In short, it works just like filter, but will compare the previous and the current value.

A very common scenario that we can use in order to explain how this operator works is receiving inputs from a text-input and skip all the events whose value is unchanged from the previous.

const textChanges$ = fromEvent(textElement, 'input');textChanges$

    .pipe(

        filter(Boolean),

        distinctUntilChanged()

    )

    .subscribe(console.log);

But this only works for primitive values. If you want to pass a more powerful equality predicate, then you can supply a function and compare manually the previous and current values.

const stream$ = /* some Rx stream with objects */

const isEqual = require('lodash/isEqual');stream$

    .pipe(

        distinctUntilChanged(isEqual)

    )

    .subscribe(/**/);

Debouncing and Throttling

Debouncing and throttling are techniques used to batch events emitted within a time window in a single emission.

These two techniques are sometimes used and referred to interchangeably even though they achieve similar things in different ways.

throttleTime

The operators throttleTime is used to only emit the first item received within the time window specified in milliseconds, then wait again for the entire amount of the time window before a subsequent event can be emitted.

const textChanges$ = fromEvent(textElement, 'input');textChanges$

    .pipe(

        filter(Boolean),

        distinctUntilChanged(),

        throttleTime(1000)

    )

    .subscribe(console.log);

Let’s explain this with a simple visual representation:

time in ms : 0---500---1000---1500---2000

events     : a_____b__________c__d___e_

Which events emitted? a and c! The first event a was collected within the time frame 0 and 1000, the second event b was skipped as it got emitted within the window. Then c emitted, and d and e were filtered.

debounceTime

Contrary to throttleTime, the operator debounceTime is used to only emit the latest item received within the time window specified in milliseconds. Just like throttling, debouncing will wait for the time windows before a new event can be emitted.

const textChanges$ = fromEvent(textElement, 'input');textChanges$

    .pipe(

        filter(Boolean),

        distinctUntilChanged(),

        debounceTime(1000)

    )

    .subscribe(console.log);

Let’s repeat the same representation used with throttleTime to understand the difference:

time in ms : 0---500---1000---1500---2000

events     : a_____b__________c__d___e_

In this scenario, only b and e emitted.

How do throttling and debouncing help?

These operators are used to delay and batch the execution of repeated events within a time frame.

They help in various situations where we want to avoid useless execution of commands or expensive operations like HTTP requests.

Imagine user-input changes that trigger requests to a server for each change: if we didn’t debounce it, we would not only spam our service but also degrade the UX for our users. In my experience, debouncing every 250 to 500 ms is the sweet spot to ensure smooth user experience.

Canceling

Canceling subscriptions is an important and too often neglected task that I see very often when reviewing PRs.

Canceling is not only important to reduce useless computations and avoid memory leaks, but also, more importantly, to prevent possible bugs in our applications.

Unsubscribing

The easiest, imperative way to cancel subscriptions is to simply call the unsubscribe method that every subscription object should have implemented.

const inputs$ = fromEvent(element, 'input');

const subscription = inputs.subscribe(/some work/);subscription.unsubscribe();

While this is a totally effective and working example for unsubscribing streams, it is usually not considered a best-practice. In fact, Rx provides powerful operators that can help us achieve the same, but in a more declarative and reactive way.

takeUntil

My favorite way of unsubscribing from streams is takeUntil. This operator will allow you to unsubscribe a stream when the stream passed as input to the operator emits an event. Oh, that seems too complicated, but it’s actually not.

Let’s see an example:

  • we have two observables that emit with an interval of respectively 1000 ms (1 second) and 100 ms
  • the stream that emits every 100ms will unsubscribe when the other stream emits, which will happen every 1 second
// emit every 1 second

const slow$ = interval(1000);// emit every 100 ms

const fast$ = interval(100).pipe(

    takeUntil(slow$)

);fast$.subscribe({

  next(n) {

    console.log(n);

  },

  complete() {

    console.log('I am unsubscribed!');

  }

});slow$.subscribe();

Which will produce the following output:

0

1

2

3

4

5

6

7

8

I am unsubscribed!

takeWhile

This operator is very useful to unsubscribe streams based on their own value. One of the ways I needed to use this operator is to stop certain timers once they reach a certain number of iterations. For instance, a countdown timer.

In the following example, I want to stop a timer once it iterates for 5 times. —

  • the takeWhile operator accepts a predicate function whose parameter is the current value of the stream
  • if the predicate is truthy, it will keep emitting values; if it’s falsy, then it will unsubscribe the stream
const stream$ = interval(1000).pipe(

  takeWhile(n => n < 5)

);

stream$.subscribe({

  next(n) {

    console.log(n)

  },

  complete() {

    console.log('I am unsubscribed!')

  }

});

Which will produce the following output:

0

1

2

3

4

I am unsubscribed!

switchMap

The operator switchMap is commonly used for flattening a stream of observables.

What you may know, is that it has a peculiar behavior: on each emission, instead of maintaining more than one inner observables, it will complete the previous inner observable and then emit the new one.

That is, if we have an in-flight HTTP request, it will be canceled when another emission takes place. Of course, depending on the observable type you use, you’d have different teardown effects.

In the example below, I created a simple snippet that will issue requests when the user inputs values in a form. The request will query Github’s API for repositories and render them on screen.

const repositoryTextInput = document.querySelector('#repositoryName');
const repositoriesElement = document.querySelector('#repositories');

const SEARCH_URL = 'https://api.github.com/search/repositories?q=';

const repositoryNameChanges$ = fromEvent(repositoryTextInput, 'input').pipe( map(e => e.target.value) );

const stopClicked$ = fromEvent(stopElement, 'click');

const repositories$ = repositoryNameChanges$.pipe( filter(Boolean), distinctUntilChanged(), debounceTime(1000), switchMap((name) => fromFetch(SEARCH_URL + name)), switchMap((response) => response.json()) );

repositories$.subscribe((repos) => { const elements = repos ? repos.items.reduce((acc, repo) => { return acc + &lt;div&gt;${repo.name}&lt;/div&gt;; }, '') : '';

repositoriesElement.innerHTML = elements; });

SwitchMap example

At the end of the article, we will revisit this example by adding a powerful caching mechanism, and the link to the code.

Batching

In situations where you repeatedly perform a very expensive operation within a very small time frame, such as re-rendering a DOM tree on updates from a stream, batching can help collect updates and render them at once.

The first time I employed this technique was when working with Angular.js: on every update from the back-end, the digest cycle was called so many times it was clocking up the application.

That’s when I thought: why not batch the updates in an array, and then update only every 1 or 2 seconds? And in order to do this, we can use the buffer or bufferTime operators (or, the other operators in the buffering family).

bufferTime

The operator bufferTime is a shortcut for the operator buffer that accepts an amount of time in milliseconds and will batch the stream every n milliseconds in an array.

For example, in the following example we mock up a stream that emits every 500 milliseconds. The buffer will be set at 2 seconds. That means, we collect 4 updates within a 2-second window.

this.stream$ = interval(500);this.data$ = this.stream$.pipe(

  bufferTime(2000),

  filter((items) => items.length > 0),

  scan((acc, items) => {

    return [...acc, ...items];

  }, [])

);this.data$.subscribe((items) => {

  /* expensive operation here */  console.log('re-render!');

});

Let’s summarise the above:

  • we have a stream that emits events with data (in the example, it’s simply an interval with numbers)
  • we batch the events every 2 seconds with bufferTime(2000)
  • we filter all the events that are empty; in our example makes little sense as we always have values, but this is something you may want to do in a real application as sometimes you’ll be receiving data that doesn’t need to be re-rendered
  • we use the scan operator that works just like Array.prototype.reduce. We collect events and group them all in an array — in case we are working with a large list we want to re-render

There are two things to notice when using this technique:

  • test performance! buffering will keep working under the hood collecting events: only use this if rendering, or another expensive operation, is a real bottleneck in your application
  • because of the above, do remember to unsubscribe the stream when not needed

Caching

Every application needs some level of caching for improving efficiency and performance. One of the most common situations where caching is important is HTTP requests, and we can leverage RxJS to make this very easily.

For example, we may not only want to return the cached response, but we may also want to stop any in-flight requests that return the same values, assuming of course that the requests are idempotent.

In the below example, we will extend our repositories search application with a cache. The cache works in this way:

  • we create a Map to store the name and the result of the request
  • when we are about to issue the request, we check if we have a cached result. If not, we go on and execute the request
  • when the request is executed, we place the observable itself in a cache, and we use the operator shareReplay(1) to store in memory the latest 1 emissions. When the observable (in the cache) is subscribed again, it will yield its result rather than issue the request again
const repositoryTextInput = document.querySelector('#repositoryName');
const repositoriesElement = document.querySelector('#repositories');

const SEARCH_URL = 'https://api.github.com/search/repositories?q='; const cache = new Map();

const repositoryNameChanges$ = fromEvent(repositoryTextInput, 'input').pipe( map(e => e.target.value) );

const stopClicked$ = fromEvent(stopElement, 'click');

const repositories$ = repositoryNameChanges$.pipe( distinctUntilChanged(), filter(Boolean), debounceTime(300), switchMap((name: string) => { if (cache.get(name)) { return cache.get(name); }

const request$ = fromFetch(SEARCH_URL + name).pipe(
  switchMap((response) =&gt; response.json()),
  tap((result) =&gt; cache.set(name, request$)),
  shareReplay(1)
);

return request$;

}) );

repositories$.subscribe((repos) => { console.log(repos); const elements = repos ? repos.items.reduce((acc, repo) => { return acc + &lt;div&gt;${repo.name}&lt;/div&gt;; }, '') : '';

repositoriesElement.innerHTML = elements; });

SwitchMap + cache Example

The example above is simplified and doesn’t take into account error-handling and such. As a result, if you use it as inspiration for your code, you may want to handle more situations.

If you want to see this in action, please visit the following Stackblitz link.

Takeaways

RxJS is an incredibly powerful tool. While its learning curve might be steep at first, learning how to use it is a great skill to add to your personal developer arsenal.

While it can easily make your code more declarative and readable, it can also help us improve the efficiency and performance of our applications with just a few lines of code added to our streams.

The techniques above are an exhaustive, yet far from complete, list of techniques that use RxJS operators to make your code efficient and performant.

If you need any clarifications, or if you think something is unclear or wrong, do please leave a comment! Feedback is always welcome.

Thanks for reading

If you liked this post, please do share/like it with all of your programming buddies!

Follow us on Facebook | Twitter

Further reading

☞ Angular + WebSocket + Node.js Express = RxJS WebSocketSubject ❤️

☞ Simple state management in Angular with only Services and RxJS

☞ Create an Audio Player app using Angular and RxJS

Originally published by Giancarlo Buomprisco at https://blog.bitsrc.io

javascript reactjs web-development angular

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

Hire Web Developer

Looking for an attractive & user-friendly web developer? HourlyDeveloper.io, a leading web, and mobile app development company, offers web developers for hire through flexible engagement models. You can **[Hire Web...

ReactJS Web App Development Services

We provide top-notch ReactJS development services to global clients. Hire expert ReactJS developers from top React JS development company, Skenix Infotech.

Why Web Development is Important for your Business

With the rapid development in technology, the old ways to do business have changed completely. A lot more advanced and developed ways are ...