DEV Community: Aziz Yokubjonov

Optimizing Observables in Angular Universal (+flickering fix) by Caching with BrowserTransferStateModule

Aziz Yokubjonov — Thu, 30 Apr 2020 18:03:34 +0000

Disclaimer

If you are simply using HttpClient to fetch your data, then you're all set since the solution for duplicate requests and flashing content is simpler and the official tutorial covers it decently well. Hopefully, that does it for you but you are welcome to keep reading if you're interested in handling other scenarios!

Why

Let's say we have a cooking blog built on Angular Universal where we share our favorite recipes. The blog has a database and we have a service BlogService to fetch our content. The code of our post-displaying component looks something like this:

import { Component, OnInit } from '@angular/core';
import { BlogService, Post } from './blog-service.service';
import { Observable } from 'rxjs';
@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent implements OnInit {
  blogPost: Observable<Post>;

  constructor(private blogService: BlogService) {
  }
  ngOnInit() {
    const URL_SLUG = 'pasta-cook';
    this.blogPost = this.blogService.getPost(URL_SLUG);
  }
}

Pretty simple and totally fine if we have a SPA. But we have an app with SSR and this will pose a few issues.

When we run the app (with SSR enabled), we'll see the following:

Weird, isn't it? We had our content there, but then it disappeared just to appear again later, resulting in a flash on the screen.

Let's look at what's happening there. If we open the Network tab in Chrome Devtools and inspect the initial page request, we can see that page markup comes hydrated with all the content, which is exactly what we want from SSR.

Note: In BlogService I'm imitating an API and every time there should be a request to the API, I'm logging "Request is made". With a real service, you'd instead look at requests being sent in the Network tab of DevTools.

As we should expect, when we load the page, the server-side makes an API call:

But in Chrome's DevTools we see that so does the browser:

This means that we are making the same request twice and thus putting an additional strain on our data servers by repeatedly fetching the same content.

To summarize, here are the steps that the code performs as we open our page in the browser:

Server fetches the post
Server renders the post
Browser fetches the same post
Browser re-renders the post

The last two steps are unnecessary and they cause the weird screen flashing and duplicate API requests. This happens naturally because with Angular's Server-Side Rendering, the code in your components always runs both on the server and in the browser unless specified otherwise.

Solution

To fix our problem, we will have to implement server-client caching. Angular's BrowserTransferStateModule is exactly what we need to do so.

In the end, we aim to have the following lifecycle:

Server fetches the post
Server saves the post to cache
Server renders the post into HTML
Browser fetches the post from cache

0. Setting up

First, we have to import BrowserTransferStateModule into app.module.ts:

import { BrowserModule, BrowserTransferStateModule } from '@angular/platform-browser';

imports: [
  BrowserModule.withServerTransition({ appId: 'serverApp' }),
  BrowserTransferStateModule,
  ...
]

In app.server.module.ts we have to import ServerTransferStateModule:

import { ServerModule, ServerTransferStateModule } from '@angular/platform-server';

imports: [
    AppModule,
    ServerModule,
    ServerTransferStateModule
],

In our working component we need to import TransferState and makeStateKey:

import { TransferState, makeStateKey } from '@angular/platform-browser';

@Component({
  ...
})
export class AppComponent implements OnInit {
    constructor(private blogService: BlogService, 
                  private state: TransferState) {
    ...

1. Saving post to cache on the server-side

To implement caching, we will use the TransferState service imported earlier. It provides us with a writeable Map (object) with string keys and values of any type. This object gets transferred from server to client.

To create these state keys, Angular provides makeStateKey. Your state keys should carry enough information to later identify the exact service call that we made on the server side. In our case it will be as follows:

const URL_SLUG = 'pasta-cook';
const dataKey = makeStateKey(`posts/${URL_SLUG}`);

Now, let's save our blogService.getPost(URL_SLUG) Observable into a variable, so we can transform its values later:

const $dataSource = this.blogService.getPost(URL_SLUG);

When we call getPost() on the server-side, we need to save its return value to our state:

if (isPlatformServer(this.platformId)) {
  this.blogPost = $dataSource.pipe(map(datum => {
    this.state.set(dataKey, datum);
    return datum;
  }), take(1));
}

2. Reading from state in the browser

When running in the browser, we need to check if getPost() was already called on the server and if so, we shouldn't make the call again:

if (isPlatformServer(this.platformId)) {
  ...
} else if (isPlatformBrowser(this.platformId)) {
  const savedValue = this.state.get(dataKey, null);
  if (savedValue) {
    this.blogPost = $dataSource.pipe(startWith(savedValue), take(1));
  } else {
    this.blogPost = $dataSource;
  }
}

The issue is now fixed and only one API request will be made on each page refresh. The annoying content flash is also gone!

3. Refactoring and reusing the code

You might say, "that was a ton of code for a single API call!" and I agree with you. The great news is that all of that code can be abstracted away and reused for all Observables. I'm moving the code to BlogService (but it's best to move it to a general utils service), where I'll define a getCachedObservable function that accepts an Observable and a state key:

getCachedObservable($dataSource: Observable<any>, dataKey: StateKey<any>) {
  if (isPlatformServer(this.platformId)) {
    return $dataSource.pipe(map(datum => {
      this.state.set(dataKey, datum);
      return datum;
    }), take(1));
  } else if (isPlatformBrowser(this.platformId)) {
    const savedValue = this.state.get(dataKey, null);
    const observableToReturn = savedValue ? $dataSource.pipe(startWith(savedValue), take(1)) : $dataSource;
    return observableToReturn;
  }
}

In our components we can simply use that function for any Observable calls:

this.blogPost = this.blogService.getCachedObservable($dataSource, dataKey);

4. (optional) Tweaking for other use-cases (i.e. Observable with 2+ values)

In the previous code, we made an assumption that we only care about the first value of our Observable. While it is perfectly fine for our blog with virtually static content, the assumption may not be valid depending on your use-case.

To see an example, let's suppose our blog article updates every couple of seconds and getPost() supplies every update. With the current implementation, we'd only ever see the first value the Observable sent us (because of the take(1) operator).

So let's remove take(1) from the logic on the browser side:

getCachedObservable($dataSource: Observable<any>, dataKey: StateKey<any>) {
  if (isPlatformServer(this.platformId)) {
    ...
  } else if (isPlatformBrowser(this.platformId)) {
    const savedValue = this.state.get(dataKey, null);
    const observableToReturn = savedValue ? $dataSource.pipe(startWith(savedValue)) : $dataSource;
    return observableToReturn;
  }
}

Now, if we open the page we'll see the updates:

Bonus - How is state transferred from server to client?

If we look at the page source in the browser, we can see that Angular transfers the state as a JSON string, which it places in a script tag at the bottom of the page and reads on the client-side:

Conclusion

The caching mechanism that I described above can significantly speed up your applications and reduce strain on your servers/computational power. Notice, that while I optimized API service calls, you can optimize any Observables in the same fashion (e.g. you have a library that performs heavy computations and returns an Observable). Lastly, Observables are just a common use-case and you can implement the same mechanism for Promises, synchronous functions, etc.

That's all I have for you today. The full source code of the mini-blog used in the article can be found here on GitHub.

You are welcome to let me know in the comments if I forgot to cover something or if you have any questions!

Setting Status Code and Handling 404 Pages in Angular Universal

Aziz Yokubjonov — Fri, 17 Jan 2020 16:59:18 +0000

If you use Angular Universal, you probably know that in addition to Server Side Rendering, Universal provides you with the full range of Node.js functionality on the server-side.

Today we will examine how to use Express.js’s popular Request and Response API within our Angular applications.

To illustrate the setup process, I’ll show how I created the simple 404 Not Found page on this blog.

Laying the foundation

Let’s first create a NotFoundComponent, to which we will redirect our users:

@Component({
 selector: 'blog-not-found',
 template: `<h2>Seems like this page doesn't exist :(</h2>`
})
export class NotFoundComponent {}

And set up proper routes and redirects for our newly-created NotFoundComponent:

... // other routes
{
   path: '404',
   component: NotFoundComponent
 },
...

Now if we go to our 404 page, we’ll see the following:

All good, right? Not quite. You see, our Not Found page clearly works for the users (except the godly design, perhaps) but robots (such as search engines) still perceive it to be a valid page of our website that needs to be indexed.

We can verify this if we look at the Network tab in the DevTools, where we see that the status code for our page is 200 (success) instead of expected 404 (not found):

Using Express.js Request and Response Objects within our application

To set the status code, we will use the Response object.
In case you’re not familiar with them, Request (aka req) and Response (aka res) are the primary way of processing HTTP requests in Express.

Providing the Response object to our Angular app

Looking at the source code of Universal, we see that unlike REQUEST, RESPONSE provider is optional and only provided if there is a res object in the RenderOptions:

if (res) {
    providers.push({
        provide: RESPONSE,
        useValue: res
    });
}

Therefore, in our server.ts file we need to add res to the RenderOptions object when rendering our pages:

app.get('*', (req, res) => {
 res.render('index', { req, res });
});

Now we can successfully inject the req and res objects into our NotFoundComponent:

import { Optional, Inject } from '@angular/core';
import { RESPONSE, REQUEST } from '@nguniversal/express-engine/tokens';
import { Request, Response } from 'express';
/*
 ...
 ...
*/
constructor(@Optional() @Inject(REQUEST) private request: Request,
            @Optional() @Inject(RESPONSE) private response: Response){

Notice that I added the @Optional() decorator. This is because Request and Response objects are purely Express concepts and thus can’t exist in the Browser context. With @Optional(), these objects will be equal to null in a Browser environment.

Setting response status code

Now that we injected the Response object into our NotFoundComponent, we can use it as follows:

if (isPlatformServer(this.platformId)) {
  this.response.status(404);
}

As I mentioned earlier, Request and Response objects are only available in the Node context, hence before using them we need to ensure we’re executing on the server side by checking isPlatformServer(...).

Full code of the NotFoundComponent:

import { Component, OnInit, Optional, Inject, PLATFORM_ID } from '@angular/core';
import { RESPONSE, REQUEST } from '@nguniversal/express-engine/tokens';
import { isPlatformServer } from '@angular/common';
import { Request, Response } from 'express';

@Component({
 selector: 'blog-not-found',
 template: `<h2>Seems like this page doesn't exist :(</h2>`
})
export class NotFoundComponent implements OnInit {
 constructor(@Optional() @Inject(REQUEST) private request: Request,
             @Optional() @Inject(RESPONSE) private response: Response,
             @Inject(PLATFORM_ID) private platformId: any) { }

 ngOnInit() {
   if (isPlatformServer(this.platformId)) {
     this.response.status(404);
   }
 }
}

Now let’s run our app once again and go to 404 with DevTools open:

As you can see, it now works just as we wanted it. Both users and robots must be tremendously happy!

Note: I didn’t show how to use the Request object here. However, once injected in the constructor (shown above), it can be used in a fashion similar to Response.