RXJS -- reactive Programming like a hero

When love is real, it doesn’t lie, cheat, pretend or keep secrets.

What’s Subject in rxjx

What is a Subject? An RxJS Subject is a special type of Observable that allows values to be multicasted to many Observers. While plain Observables are unicast (each subscribed Observer owns an independent execution of the Observable), Subjects are multicast.

A Subject is like an Observable, but can multicast to many Observers. Subjects are like EventEmitters: they maintain a registry of many listeners.

Lettable operators

RxJS 5.5, piping all the things

So now we want a way to use those operators, how could we do that?

Well, we said those operators are “lettable” that means we can use them by calling the let method on an observable:

And if we want to chain multiple lettable operators we can keep dot chaining:

import { Observable } from 'rxjs/Rx';
import { filter, map, reduce } from 'rxjs/operators';

const filterOutEvens = filter(x => x % 2);
const sum = reduce((acc, next) => acc + next, 0);
const doubleBy = x => map(value => value * x);

const source$ = Observable.range(0, 10);

source$
  .let(filterOutEvens)
  .let(doubleBy(2))
  .let(sum)
  .subscribe(x => console.log(x)); // 50

Meaning we can easily compose a bunch of pure function operators and pass them as a single operator to an observable!

Conclusion With those tools in hand, you can write RxJS code that is much more re-usable by just piping your (pure functions) operators together and easily re-use shared logic.

import { Observable, pipe } from 'rxjs/Rx';
import { filter, map, reduce } from 'rxjs/operators';

const filterOutEvens = filter(x => x % 2);
const sum = reduce((acc, next) => acc + next, 0);
const doubleBy = x => map(value => value * x);

const complicatedLogic = pipe(
  filterOutEvens,
  doubleBy(2),
  sum
);

const source$ = Observable.range(0, 10);

source$.let(complicatedLogic).subscribe(x => console.log(x)); // 50

What? What is a pipeable operator? Simply put, a function that can be used with the current let operator. It used to be the origin of the name (“lettable”), but that was confusing and we call them “pipeable” now because they’re intended to be used with the pipe utility. A pipeable operator is basically any function that returns a function with the signature: <T, R>(source: Observable<T>) => Observable<R>.

There is a pipe method built into Observable now at Observable.prototype.pipe that сan be used to compose the operators in similar manner to what you’re used to with dot-chaining (shown below).

There is also a pipe utility function at rxjs/util/pipe that can be used to build reusable pipeable operators from other pipeable operators.

Usage

You pull in any operator you need from one spot, under ‘rxjs/operators’ (**plural((!). It’s also recommended to pull in the Observable creation methods you need directly as shown below with range:

import { range } from 'rxjs/observable/range';
import { map, filter, scan } from 'rxjs/operators';

const source$ = range(0, 10);

source$.pipe(
  filter(x => x % 2 === 0),
  map(x => x + x),
  scan((acc, x) => acc + x, 0)
)
.subscribe(x => console.log(x))

What are lettable operators and what does lettable mean?

If lettable operators are used with a method named pipe, you might wonder why they are referred to as lettable. The term is derived from RxJS’s let operator.

The let operator is conceptually similar to the map operator, but instead of taking a projection function that receives and returns a value, let takes a function that receives and returns an observable. It’s unfortunate that let is one of the less-well-known operators, as it’s very useful for composing reusable functionality.

import * as Rx from "rxjs";

export function retry<T>(
  count: number,
  wait: number
): (source: Rx.Observable<T>) => Rx.Observable<T> {

  return (source: Rx.Observable<T>) => source
    .retryWhen(errors => errors
      // Each time an error occurs, increment the accumulator.
      // When the maximum number of retries have been attempted, throw the error.
      .scan((acc, error) => {
        if (acc >= count) { throw error; }
        return acc + 1;
      }, 0)
      // Wait the specified number of milliseconds between retries.
      .delay(wait)
    );
}

When retry is called, it’s passed the number of retry attempts that should be made and the number of milliseconds to wait between attempts, and it returns a function that receives an observable and returns another observable into which the retry logic is composed. The returned function can be passed to the let operator, like this:

import * as Rx from "rxjs";
import { retry } from "./retry";

const name = Rx.Observable.ajax
  .getJSON<{ name: string }>("/api/employees/alice")
  .let(retry(3, 1000))
  .map(employee => employee.name)
  .catch(error => Rx.Observable.of(null));

Using the let operator, we’ve been able to create a reusable function much more simply than we would have been able to create a prototype-patching operator. What we’ve created is a lettable operator.

Lettable operators are a higher-order functions. Lettable operators return functions that receive and return observables; and those functions can be passed to the let operator.

We can also use our lettable retry operator with pipe, like this:

import { ajax } from "rxjs/observable/dom/ajax";
import { of } from "rxjs/observable/of";
import { catchError, map } from "rxjs/operators";
import { retry } from "./retry";

const name = ajax
  .getJSON<{ name: string }>("/api/employees/alice")
  .pipe(
    retry(3, 1000),
    map(employee => employee.name),
    catchError(error => of(null))
  );

Let’s return to our retry function and replace the chained methods with lettable operators and a pipe call, so that it looks like this:

import { Observable } from "rxjs/Observable";
import { delay, retryWhen, scan } from "rxjs/operators";

export function retry<T>(
  count: number,
  wait: number
): (source: Observable<T>) => Observable<T> {

  return retryWhen(errors => errors.pipe(
    // Each time an error occurs, increment the accumulator.
    // When the maximum number of retries have been attempted, throw the error.
    scan((acc, error) => {
      if (acc >= count) { throw error; }
      return acc + 1;
    }, 0),
    // Wait the specified number of milliseconds between retries.
    delay(wait)
  ));
}

With the chained methods replaced, we now have a proper, reusable lettable operator that imports only what it requires.

Why should lettable operators should be preferred?

For application developers, lettable operators are much easier to manage:

• Rather then relying upon operators being patched into Observable.prototype, lettable operators are explicitly imported into the modules in which they are used.
• It’s easy for TypeScript and bundlers to determine whether the lettable operators imported into a module are actually used. And if they are not, they can be left unbundled. If prototype patching is used, this task is manual and tedious.
• For library authors, lettable operators are much less verbose than call-based alternative, but it’s the correct inference of types that is — at least for me — the biggest advantage.

Agreed, the pipe is awesome for composing custom rx operators. But why do we see more and more people using it even when not combining re-usable variables — instead of just chaining methods?

Meaning, we use to write e.g…

const source$ = Observable.range(0, 10); 
source$
  .filter(x => x % 2)
  .reduce((acc, next) => acc + next, 0)
  .map(value => value * 2)
  .subscribe(x => console.log(x));

Above is imho much cleaner than what I see more nowadays:

const source$ = Observable.range(0, 10);
source$.pipe(
  filter(x => x % 2),
  reduce((acc, next) => acc + next, 0),
  map(value => value * 2)
).subscribe(x => console.log(x));

Are there performance advantages by using the standalone operators instead of chaining?

debounceInput is a function that takes and returns an observable, so it can be passed to the Observable.prototype.pipe function, like this: valueChanges.pipe(debounceInput).

So, whenever you find yourself using the same combination of operators in many places, you could consider using the static pipe function to create a reusable operator combination.

The static pipe function also makes something else much simpler: dealing with pipe-like overload signatures. Let’s look at that next.

Tree Shaking

https://webpack.js.org/guides/tree-shaking/ Tree shaking is a term commonly used in the JavaScript context for dead-code elimination. It relies on the static structure of ES2015 module syntax, i.e. import and export. The name and concept have been popularized by the ES2015 module bundler rollup.

So, what we’ve learned is that in order to take advantage of tree shaking, you must…

Use ES2015 module syntax (i.e. import and export). Add a “sideEffects” entry to your project’s package.json file. Include a minifier that supports dead code removal (e.g. the UglifyJSPlugin).

mergeMap vs flatMap vs concatMap vs switchMap

Today we’re going to look at the difference between these four three RxJS operators. The simple part is that flatMap is just an alias for mergeMap. Other operators have a difference that might be important in some cases.

When do you need them?

All these operators are used with so-called higher order Observables. This is when items of an Observable are Observables themselves (or they are mapped to Observables) and we need to flatten all of them into one final Observable. You can easily identify this situation when you subscribe to an Observable inside subscription to another Observable (Note: this is not a recommended approach):

outerObservable.subscribe(outerItem => {
    outerItem.subsribe(innerItem => {
            foo(innerItem);
        })});

In my examples, initial Observable is called outer Observable. And items of the outer Observable are called inner Observables. Technically inner and outer Observables are just plain Observables.

A usage example for such operators can be a search box (search box text changes as outer Observable) with a request being sent to a server for each search text change (HTTP responses as inner Observables). Another example is mouse button clicks (outer Observable) that trigger an interval timer for each mouse click (timer events as inner Observables).

Learning plan To tackle these operators you need to understand more basic ones first. In this article I won’t give any definitions or explanations per se, but rather just a small learning plan with links:

Map, Merge, Concat. Basic Observable operators. MergeAll, ConcatAll, Switch. These are for higher order Observables already. After that MergeMap, ConcatMap, and SwitchMap should be easy for you. Operators from the third group are two step operators. First, they map outer Observable items to inner Observables. The second step is to merge a result set of inner Observables in some way. The way they are merged depends on the operator you use.

mergeMap = map + mergeAll
concatMap = map + concatAll
switchMap = map + switch

Here are some reworked reactivex.io diagrams. At first some explanations for the diagrams:

MergeMap

Outer (initial) Observable emits circles. Each circle is then mapped to its own inner Observable - collection of rhombuses. Collections are identified by color; each collection has its own color. All those inner Observables are then merged into one final Observable - resulting collection of rhombuses.

MergeMap mergeMap emits items into the resulting Observable just as they are emitted from inner Observables. It doesn’t wait for anything. mergeMap doesn’t preserve the order from outer Observable. Collections of rhombuses interleave. mergeMap doesn’t cancel any inner Observables. All rhombuses from inner Observables get to final collection.

ConcatMap

concatMap waits for inner Observable to complete before taking items from the next inner Observable. concatMap does preserve the order from outer Observable. Collections of rhombuses don’t interleave. Just as mergeMap, concatMap doesn’t cancel any inner Observables. All rhombuses from inner Observables get to the final collection.

SwitchMap

switchMap emits items only from the most recent inner Observable. switchMap cancels previous inner Observables when a new inner Observable appears. Items of inner Observable that were emitted after the Observable was canceled will be lost (not included in the resulting Observable).

“Talk is cheap. Show me the code.” I still wasn’t sure I had cracked the difference between the discussed operators even after reading all the results from Google’s first page :) I’ve set up a small example on JsFiddle to see the difference in practice.

In the example, outer Observable emits three items with a one-second interval. Each item is then mapped to an inner Observable, which in its turn emits another three items with a one-second interval. The final result depends on the operator you use. Hope this small example will help you understand these operators without too much googling.

Router

const appRoutes: Routes = [
  { path: 'crisis-center', component: CrisisListComponent },
  { path: 'hero/:id',      component: HeroDetailComponent },
  {
    path: 'heroes',
    component: HeroListComponent,
    data: { title: 'Heroes List' }
  },
  { path: '',
    redirectTo: '/heroes',
    pathMatch: 'full'
  },
  { path: '**', component: PageNotFoundComponent }
];

@NgModule({
  imports: [
    RouterModule.forRoot(
      appRoutes,
      { enableTracing: true } // <-- debugging purposes only
    )
    // other imports here
  ],
  ...
})
export class AppModule { }

• The data property in the third route is a place to store arbitrary data associated with this specific route. The data property is accessible within each activated route. Use it to store items such as page titles, breadcrumb text, and other read-only, static data. You’ll use the resolve guard to retrieve dynamic data
• The empty path in the fourth route represents the default path for the application, the place to go when the path in the URL is empty, as it typically is at the start. This default route redirects to the route for the /heroes URL and, therefore, will display the HeroesListComponent.
• The ** path in the last route is a wildcard. The router will select this route if the requested URL doesn’t match any paths for routes defined earlier in the configuration. This is useful for displaying a “404 - Not Found” page or redirecting to another route.
• The order of the routes in the configuration matters and this is by design. The router uses a first-match wins strategy when matching routes, so more specific routes should be placed above less specific routes.

Router outlet

The router matches that URL to the route path and displays the Component after a RouterOutlet that you’ve placed in the host view’s HTML.

content_copy
<router-outlet></router-outlet>
<!-- Routed views go here -->

Define routes

A router must be configured with a list of route definitions.

mechanism

• When the application requests navigation to the path /crisis-center, the router activates an instance of CrisisListComponent, displays its view, and updates the browser’s address location and history with the URL for that path.
• Pass the array of routes, appRoutes, to the RouterModule.forRoot method. It returns a module, containing the configured Router service provider, plus other providers that the routing library requires. Once the application is bootstrapped, the Router performs the initial navigation based on the current browser URL

Some key points of setting up router

• Load the router library.
• Add a nav bar to the shell template with anchor tags, routerLink and routerLinkActive directives.
• Add a router-outlet to the shell template where views will be displayed.
• Configure the router module with RouterModule.forRoot.
• Set the router to compose HTML5 browser URLs.
• handle invalid routes with a wildcard route.
• navigate to the default route when the app launches with an empty path.

Difference between forRoot and forChild

Only call RouterModule.forRoot in the root AppRoutingModule (or the AppModule if that’s where you register top level application routes). In any other module, you must call the RouterModule.forChild method to register additional routes.

Leave the default and the wildcard routes! These are concerns at the top level of the application itself.

Reference

• https://angular.io/guide/router

• 2024 15
• 2023 101
• 2022 53
• 2021 19
• 2020 25
• 2019 7
• 2018 39
• 2017 38
• 2016 50