Server Setup

As mentioned, the server we will be working with is already developed and available in the repository in the chapter9/server folder. Before we start any web development, let’s get our server up and running.

Checkout and browse to the chapter9/server folder in the GitHub repository. From within the folder, execute the following commands in your terminal :

npm i
node index.js

This installs all the necessary dependencies for our Node.js server, and then starts the server on port 3000. Keep this server running in the background; don’t kill it. This will be what our application hits to fetch and save stocks.

Using HttpClientModule

In case you are not coding along, you can get the base code from the chapter8/observables folder in the GitHub repository.

Now let’s get to our web application, and see step by step how to convert our local web application to talk to a server and fetch its data. While doing this, we will also see how easy this switch is, since we are already using observables in our code.

The very first thing we will do is add a dependency on HttpClientModule in our AppModule. Let’s modify the src/app/app.module.ts file as follows:

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { FormsModule } from '@angular/forms';
import { HttpClientModule } from '@angular/common/http';    

import { AppComponent } from './app.component';
import { StockItemComponent } from './stock/stock-item/stock-item.component';
import { CreateStockComponent } from './stock/create-stock/create-stock.component';
import { StockListComponent }
    from './stock/stock-list/stock-list.component';
import { StockService } from 'app/services/stock.service';

@NgModule({
  declarations: [
    AppComponent,
    StockItemComponent,
    CreateStockComponent,
    StockListComponent
  ],
  imports: [
    BrowserModule,
    FormsModule,
    HttpClientModule                                         
  ],
  providers: [
    StockService,
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }

Import the HttpClientModule instead of HttpModule

Add HttpClientModule to the imports array

Making HTTP GET/POST Calls

Next, we will change the implementation of our StockService to actually make an HTTP service call instead of just returning an observable of mock data. To do this, we get the HttpClient service injected into the constructor (thanks, Angular dependency injection!), and then use it to make our calls. Let’s see how we can modify the src/app/services/stock.service.ts file:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';

import { Observable } from 'rxjs/Observable';

import { Stock } from 'app/model/stock';

@Injectable()
export class StockService {

  constructor(private http: HttpClient) {}

  getStocks() : Observable<Stock[]> {
    return this.http.get<Stock[]>('/api/stock');
  }

  createStock(stock: Stock): Observable<any> {
    return this.http.post('/api/stock', stock);
  }

  toggleFavorite(stock: Stock): Observable<Stock> {
    return this.http.patch<Stock>('/api/stock/' + stock.code,
      {
        favorite: !stock.favorite
      });
  }
}

Our server exposes three APIs:

• GET on /api/stock to get a list of stocks

• POST on /api/stock with the new stock as a body to create a stock on the server

• PATCH on /api/stock/:code with the stock code in the URL and the new favorite status in the body of the request, to change the state of favorite for the particular stock.

Our StockService mirrors this API, with each of the three methods making the respective call. The HttpClient APIs directly mirror the HTTP methods, as we can call httpClient.get, httpClient.post, and httpClient.patch directly. Each of them take the URL as the first argument, and a request body as the second (if the method supports it).

One important thing to note is that the HttpClient can give you type-assurance across your code. We leverage this feature in the getStocks() and the toggleFavorite() methods.

One effect of this is that we need to change our stock.ts from a TypeScript class to a TypeScript interface. Why is this? While we don’t need to, Angular does a simple typecast of the response body into the type we have defined. But TypeScript (and ECMAScript underneath it) has no nice and easy way to convert a simple plain-old JavaScript object into a prototypical JavaScript/TypeScript class object. This means that while our response from StockService will have all the properties of the class Stock, it would not have the functions (in particular, isPositiveChange()) available.

We could write a converter, but it is only worth it in very specific cases. It is easier to simply leverage TypeScript for type safety and work with other ways of encapsulation (either at a component level, or maybe as an Angular service).

For these reasons, let’s switch our Stock class to an interface, by editing src/app/model/stock.ts as follows:

export interface Stock {
  name: string;
  code: string;
  price: number;
  previousPrice: number;
  exchange: string;
  favorite: boolean;
}

We have simply converted it to an interface, and defined all the properties on it. No more constructor, no more built-in functions. With that groundwork done, let’s now move to changing the components over to using the service correctly. We will first start with StockListComponent, which has minimal changes. All we will do is remove the toggling of favorites functionality away from this component, and let each individual stock component handle it. Let’s see the changes to src/app/stock/stock-list/stock-list.component.ts:

import { Component, OnInit } from '@angular/core';
import { StockService } from 'app/services/stock.service';
import { Stock } from 'app/model/stock';
import { Observable } from 'rxjs/Observable';

@Component({
  selector: 'app-stock-list',
  templateUrl: './stock-list.component.html',
  styleUrls: ['./stock-list.component.css']
})
export class StockListComponent implements OnInit {

  public stocks$: Observable<Stock[]>;
  constructor(private stockService: StockService) { }

  ngOnInit() {
    this.stocks$ = this.stockService.getStocks();
  }
}

Our StockListComponent becomes simplified with this change. We also have to make a slight tweak to its template, to remove the toggleFavorite event binding. Change src/app/stock/stock-list/stock-list.component.html as follows:

<app-stock-item *ngFor="let stock of stocks$ | async"
                [stock]="stock">
</app-stock-item>

Next, let’s move on to the StockItemComponent. We will move the toggleFavorite logic into the component here, and ask each individual stock to make the respective server call through StockService.toggleFavorite directly, and handle the response. We will remove the EventEmitter while we are at it. The finished src/app/stock/stock-item/stock-item.component.ts file should look like this:

import { Component, OnInit, Input } from '@angular/core';

import { Stock } from '../../model/stock';
import { StockService } from 'app/services/stock.service';

@Component({
  selector: 'app-stock-item',
  templateUrl: './stock-item.component.html',
  styleUrls: ['./stock-item.component.css']
})
export class StockItemComponent {

  @Input() public stock: Stock;              

  constructor(private stockService: StockService) {}    

  onToggleFavorite(event) {                   
    this.stockService.toggleFavorite(this.stock)
      .subscribe((stock) => this.stock.favorite = !this.stock.favorite);
  }
}

Only have input, remove the output binding

Inject StockService into the constructor

Change onToggleFavorite to call the service instead

Note that we are taking responsibility for toggling the local state of favorite on the stock on successful toggle favorite call. Without it, it would change the state on the server, but the local browser state would not be changed. We could also have chosen to refresh the entire list of stocks on every toggle favorite, by keeping the EventEmitter and asking the parent StockListComponent to refetch the list of stocks every time. That is a call we can make as we develop our applications, depending on our needs. There will be times when we want the latest and greatest information from the server, and times when handling changes locally is acceptable.

There is also a change in our template for the StockItemComponent, as we no longer have access to the isPositiveChange() function on the stock. We instead directly calculate whether it is positive or not using the underlying properties in our template. Our changed src/app/stock/stock-item/stock-item.component.html should look as follows:

<div class="stock-container">
  <div class="name">{{stock.name + ' (' + stock.code + ')'}}</div>
  <div class="exchange">{{stock.exchange}}</div>
  <div class="price"
      [class.positive]="stock.price > stock.previousPrice"     
      [class.negative]="stock.price <= stock.previousPrice">   
      $ {{stock.price}}
  </div>
  <button (click)="onToggleFavorite($event)"
          *ngIf="!stock.favorite">Add to Favorite</button>
  <button (click)="onToggleFavorite($event)"
          *ngIf="stock.favorite">Remove from Favorite</button>
</div>

Add positive class binding based on stock price

Add negative class binding based on stock price

Now, we will move to the last component, the CreateStockComponent. We only have to accommodate the change over from the class to the interface, which means we don’t have a nice constructor for a Stock object. While we are it, we will refactor the class for reuse. But there is no change required with respect to HttpClient, since we abstracted out the logic and used observables from the beginning. The finished src/app/stock/create-stock/create-stock.component.ts file should look like this:

import { Component, OnInit } from '@angular/core';
import { Stock } from 'app/model/stock';
import { StockService } from 'app/services/stock.service';

@Component({
  selector: 'app-create-stock',
  templateUrl: './create-stock.component.html',
  styleUrls: ['./create-stock.component.css']
})
export class CreateStockComponent {

  public stock: Stock;
  public confirmed = false;
  public message = null;
  public exchanges = ['NYSE', 'NASDAQ', 'OTHER'];
  constructor(private stockService: StockService) {
    this.initializeStock();           
  }

  initializeStock() {                 
    this.stock =  {
      name: '',
      code: '',
      price: 0,
      previousPrice: 0,
      exchange: 'NASDAQ',
      favorite: false
    };
  }

  setStockPrice(price) {
    this.stock.price = price;
    this.stock.previousPrice = price;
  }

  createStock(stockForm) {
    if (stockForm.valid) {
      this.stockService.createStock(this.stock)
          .subscribe((result: any) => {
            this.message = result.msg;
            this.initializeStock();      
          }, (err) => {
            this.message = err.error.msg;
          });
    } else {
      console.error('Stock form is in an invalid state');
    }
  }
}

Call initializeStock to create a stock instance

Define initializeStock method for reuse

Use initializeStock after stock is successfully created

We just pulled out an initializeStock function, which we call both from the constructor as well as after the stock is successfully created. The only other change we did in this class is how we handled the error. With HttpResponse for errors, the response body is actually available in the error key inside the response, so we grab the msg key from there instead. There are no other changes we need to do in this class. The template also remains as is.

We are now almost ready to run our application, but we have one final change we need to make. The browser, for security reasons, does not allow you to make calls across domains and origins. Thus, even while both our server and the Angular application are running on localhost, they are running on different ports, and thus the browser treats them as different origins. To get around this, the Angular CLI allows us to set up a proxy, so that our requests would be sent to the server, which would then proxy it to our final endpoint.

To do this, we will create a file proxy.conf.json in the main folder of our Angular application, with the following contents:

{
  "/api": {
    "target": "http://localhost:3000",
    "secure": false
  }
}

What we have done is simply asked Angular to proxy all requests made to the server with the path starting with /api to our Node.js server running on port 3000 locally. Technically, this filename can be anything, but we are just following a certain pattern. This file supports a lot more configuration, but we will not get into it in this book. You can read up on it in the official Angular CLI docs.

Now we are finally ready to run our application. So far, we have been running the application using ng serve. Now, we need to run it with the following command:

ng serve --proxy-config proxy.conf.json

This will let Angular run our application, but taking our proxy configuration into account. Now, when you browse to our application (http://localhost:4200), you should see the list of stocks coming from the server. Note that if you create a new stock, you will see a message saying it has been added successfully, but you will have to manually refresh the page to see it updated in the UI. Toggling the stock should also work, and this should be persisted even after you refresh the page. The application should look exactly the same as it has been looking so far, as we have not made any UI-specific changes.

The finished code sample for this section is available in the GitHub repository in the chapter9/simple-http folder.

Options—Headers/Params

First, let’s take a closer look at the HTTP API we invoke. So far, we passed it a URL, along with a body for the request if necessary. The HTTP API also allows us to pass an options object as the second (or third in case the API allows for a body like POST and PATCH) argument to the function. Again, let’s modify our existing application to see these options, and add in some common requirements as well. We will use the codebase from the previous section, which can be obtained from the chapter9/simple-http folder in case you are not coding along, as a base.

First, one of the common tasks that any developer has with an HTTP API is to send additional query parameters, or certain HTTP headers along with the request. Let’s see how we can accomplish this using the HttpClient. We will change the src/app/services/stock.service.ts file as follows:

import { Injectable } from '@angular/core';
import { HttpClient, HttpHeaders } from '@angular/common/http';

import { Observable } from 'rxjs/Observable';

import { Stock } from 'app/model/stock';

@Injectable()
export class StockService {

  constructor(private http: HttpClient) {}

  getStocks() : Observable<Stock[]> {
    return this.http.get<Stock[]>('/api/stock', {
      headers: new HttpHeaders()                      
          .set('Authorization', 'MyAuthorizationHeaderValue')
          .set('X-EXAMPLE-HEADER', 'TestValue'),
      params: {                                       
        q: 'test',
        test: 'value'
      }
    });
  }

  /** Unchanged after this, omitted for brevity */
}

Add HTTP headers to the outgoing call

Add query params q and test to the outgoing call

In the preceding code, we have made two changes. We have added a second argument to the http.get call, which is an options object. There are certain keys we can pass to it, to configure the outgoing HTTP request. In the code, we have added two options:

headers

We can set the outgoing/request HTTP headers. There are two ways we can set both the headers as well as the parameters. One option, as we have done in the code, is to pass an HttpHeaders object, which is a typed class instance, on which we can call set to set the correct headers. It follows a builder pattern, so you can chain multiple headers as we have done. The second option is to just pass it a plain-old JavaScript object. Of course, for the values, we have hardcoded it here, but you can just as well access it from some variable, or even some other service (in case you need to get authorization headers from, say, an AuthService).

params

Just like the headers, HTTP query parameters can also be configured in two ways: using the typed, built-in HttpParams class, or using a plain-old JavaScript object.

Now, when we run this code (making sure that the Node.js server is also running in parallel), open your network inspector to see the outgoing requests. You should see something like Figure 9-1.

Figure 9-1. Sending query params and headers with an Angular HTTP request

The finished code is available in the chapter9/http-api folder.

Options—Observe/Response Type

We will next move on to two other options on the HTTP request, which give you flexibility in a variety of use cases. The first one we will focus on is the observe property on the options parameter.

The observe parameter takes one of three values:

body

This is the default value, which ensures that the observable’s subscribe gets called with the body of the response. This body is auto-casted to the return type specified when calling the API. This is what we have been using so far.

response

This changes the response type of the HTTP APIs from returning the entire HttpResponse instead of just the body. The response still holds a typed response, so you can still access it underneath, but you also get access to the headers of the response and the status code. Note that instead of a raw HttpResponse, what you really get is an HttpResponse<T>, where T is the type of the body. So in the case of getStocks, what you would end up returning is actually an observable of HttpResponse<Stock[]>.

events

This is similar to response, but gets triggered on all HttpEvents. This would include the initialization event, as well as the request finished event. These correspond to the XMLHttpRequest states. This is more useful when we have an API that sends progress events, as we can catch and listen to progress events as well with the observe parameter set to events.

The second parameter that we will explore is the responseType property on the options parameter. This can take one of four values:

json

This is the default, which basically ensures that the response body is parsed and treated as a JSON object. In most cases, you wouldn’t need to change this from the default.

text

This allows you to treat the response body as a string, without parsing it at all. In this case, the response from your HTTP request would be an Observable<string> instead of a typed response.

blob

Both this and the next option are more useful when dealing with binary responses that you need to handle in your application. blob gives you a file-like object containing the raw immutable data, which you can then process as you see fit.

arraybuffer

The last option gives us the underlying raw binary data directly.

Let’s take a look at some of these in action. We will change the StockService temporarily to try the same API with a few of these values set as options. Change the src/app/services/stock.service.ts file as follows:

/** No Change in Imports */

@Injectable()
export class StockService {

  constructor(private http: HttpClient) {}

  getStocks() : Observable<Stock[]> {
    return this.http.get<Stock[]>('/api/stock', {
      headers: new HttpHeaders()
          .set('Authorization', 'MyAuthorizationHeaderValue')
          .set('X-EXAMPLE-HEADER', 'TestValue'),
      params: {
        q: 'test',
        test: 'value'
      },
      observe: 'body'                 
    });
  }

  getStocksAsResponse(): Observable<HttpResponse<Stock[]>> {
    return this.http.get<Stock[]>('/api/stock', {
      observe: 'response'                 
    });
  }

  getStocksAsEvents(): Observable<HttpEvent<any>> {
    return this.http.get('/api/stock', {
      observe: 'events'                 
    });
  }

  getStocksAsString(): Observable<string> {
    return this.http.get('/api/stock', {
      responseType: 'text'                 
    });
  }

  getStocksAsBlob(): Observable<Blob> {
    return this.http.get('/api/stock', {
      responseType: 'blob'                 
    });
  }

  /** Remaining code unchanged, omitted for brevity */
}

Observe response body only

Observe entire response

Observe all events

Response to be treated as text

Response to be treated as blob

We have added four new methods to the StockService as follows:

• getStocksAsResponse makes the same HTTP call, but sets the observe value to response. This also changes the response of the function to return an Observable<HttpResponse<Stock[]>>.

• getStocksAsEvents makes the same HTTP call, but sets the observe value to events. This also changes the response of the function to return an Observable<HttpEvent<any>>. This is because we will get multiple instances of Http​Event that are not just the response, but also progress, initialization, etc. Thus the format of the response is not defined.

• getStocksAsString makes the same HTTP call, but sets the responseType value to text. We also change the response type of the function to return an Observable<string>, and the string is the entire body as a string.

• getStocksAsBlob makes the same HTTP call, but sets the responseType value to blob. We also change the response type of the function to return an Observable<Blob> to allow the subscriber to work with the blob once we get a response from the server.

Now, let’s hook this up in the component so that we see the effect of calling each of these slightly different APIs. We will modify the StockListComponent to make calls to each of these APIs so that we can see and compare them side by side. Modify the src/app/stock/stock-list/stock-list.component.ts file as follows:

import { Component, OnInit } from '@angular/core';
import { StockService } from 'app/services/stock.service';
import { Stock } from 'app/model/stock';
import { Observable } from 'rxjs/Observable';

@Component({
  selector: 'app-stock-list',
  templateUrl: './stock-list.component.html',
  styleUrls: ['./stock-list.component.css']
})
export class StockListComponent implements OnInit {

  public stocks$: Observable<Stock[]>;
  constructor(private stockService: StockService) { }

  ngOnInit() {
    this.stocks$ = this.stockService.getStocks();
    this.stockService.getStocksAsResponse()
        .subscribe((response) => {
          console.log('OBSERVE "response" RESPONSE is ', response);
        });

    this.stockService.getStocksAsEvents()
        .subscribe((response) => {
          console.log('OBSERVE "events" RESPONSE is ', response);
        });

    this.stockService.getStocksAsString()
        .subscribe((response) => {
          console.log('Response Type "text" RESPONSE is ', response);
        });

    this.stockService.getStocksAsBlob()
        .subscribe((response) => {
          console.log('Response Type "blob" RESPONSE is ', response);
        });
  }
}

In the StockListComponent, we leave the original call untouched, and simply add calls to each of the other functions we added in the service below it. For each, we simply subscribe to the response, and then print it (with a respective log so that we can identify them separately). Now, when you run it, make sure you have your browser developer tools open so that you can see the logs it prints. You should see something like Figure 9-2.

Figure 9-2. Different kind of response types in Angular

There are a few interesting things to note in the example we ran:

• For the getStocksAsEvents() call, our subscription is actually called twice, once for the initialization/request being sent and once when the actual information has been loaded with the response. The second event is the one that has the actual data. If our API supported progress, then the subscription would get called for progress events as well.

• The getStocksAsResponse() call is similar to our initial getStocks() call, except it gives the body along with other HTTP request fields like status, headers, etc.

• The getStocksAsString() call is similar to our original call, but instead of getting a typed JSON response, we get our entire JSON response as a string. As mentioned before, this is more useful for working with non-JSON APIs.

• The final getStocksAsBlob() call returns a blob containing our data that we can then work with. This is more useful for working with binary data and the like, rather than JSON APIs.

For the most part, you wlll only need the default setting of observing the body and using the json response type. These other options exist for that 5% of use cases where the default is not enough, and you need access to something more. The new HttpClient gives you that flexibility to work with your APIs the way you want to, while making it easy for the most common use cases.

The finished code sample for this section is available in the GitHub repository in the chapter9/http-api folder.

Interceptors

One other common use case is to be able to hook into all incoming and outgoing requests to be able to either modify them in flight, or listen in on all responses to accomplish things like logging, handling authentication failures in a common manner, etc.

With the HttpClient API, Angular allows easily defining interceptors, which can conceptually sit between the HttpClient and the server, allowing it to transform all outgoing requests, and listen in and transform if necessary all incoming responses before passing them on. Let’s see how we might create a very simple interceptor in Angular that allows us to:

• Modify all outgoing requests by adding a header if we have an authorization token.

• Log all incoming responses before passing them along.

• In case the request ends up in a failure (a non-200 or non-300 response), we will log it differently.

We will fetch the authorization token from another service, which we will create just for the purpose of storing and returning our authorization information. To complete this example, we will build on our codebase from the first section. So if you want, you can obtain the base code from the chapter9/simple-http folder. Note that we are not using the additions we did while we were exploring the HTTP API.

We will first add a very simple service that acts as a holder of authorization-related information. We can add it simply by running this from the terminal:

ng generate service services/auth --module=app

This will create an AuthService for you, and also hook up the provider in the AppModule. We will just make a small change to the generated service to hold a property that we can use in our interceptor. The changed service in src/app/services/auth.service.ts should look like the following:

import { Injectable } from '@angular/core';

@Injectable()
export class AuthService {

  public authToken: string;

  constructor() { }
}

We have added a public property on the class called authToken in the AuthService. Because we generated the service using the Angular CLI, it automatically added the provider in the AppModule. Otherwise, we would have had to do it ourselves. We will add one more HTTP API call in the StockService to an API that always returns a 403. Make the change so that the src/app/services/stock.service.ts file looks like this:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';

import { Observable } from 'rxjs/Observable';

import { Stock } from 'app/model/stock';

@Injectable()
export class StockService {

  constructor(private http: HttpClient) {}

  /** No changes to other calls, omitting for brevity */

  makeFailingCall() {
    return this.http.get('/api/fail');
  }
}

We only added the last method, makeFailingCall(), to the StockService. The remaining code remains untouched. We will then change the StockListComponent to display a few extra buttons, which we will hook up to the StockService and the AuthService that we have just created. First, change the src/app/stock/stock-list/stock-list.component.ts file as follows:

import { Component, OnInit } from '@angular/core';
import { StockService } from 'app/services/stock.service';
import { Stock } from 'app/model/stock';
import { Observable } from 'rxjs/Observable';
import { AuthService } from 'app/services/auth.service';

@Component({
  selector: 'app-stock-list',
  templateUrl: './stock-list.component.html',
  styleUrls: ['./stock-list.component.css']
})
export class StockListComponent implements OnInit {

  public stocks$: Observable<Stock[]>;
  constructor(private stockService: StockService,
              private authService: AuthService) { }

  ngOnInit() {
    this.fetchStocks();
  }

  fetchStocks() {
    this.stocks$ = this.stockService.getStocks();
  }

  setAuthToken() {
    this.authService.authToken = 'TESTING';
  }

  resetAuthToken() {
    this.authService.authToken = null;
  }

  makeFailingCall() {
    this.stockService.makeFailingCall().subscribe(
      (res) => console.log('Successfully made failing call', res),
      (err) => console.error('Error making failing call', err));
  }
}

We made a slight change to the initialization logic, and added a few new methods to the StockListComponent. First, we pulled out the stock$ Observable subscription to a new method called fetchStocks(), and just called it in the ngOnInit. Next, we have added a few more methods, namely setAuthToken(), resetAuthToken(), and makeFailingCall(), all of which are trivial and basically call out to AuthService and StockService, respectively.

Next, we will hook these four new methods to buttons in the template for the StockListComponent. Let’s change src/app/stock/stock-list/stock-list.component.html as follows:

<app-stock-item *ngFor="let stock of stocks$ | async"
                [stock]="stock">
</app-stock-item>

<div>
  <button type="button"
          (click)="fetchStocks()">
    Refetch Stocks
  </button>
  <button type="button"
          (click)="makeFailingCall()">
    Make Failing Call
  </button>
  <button type="button"
          (click)="setAuthToken()">
    Set Auth Token
  </button>
  <button type="button"
          (click)="resetAuthToken()">
    Reset Auth Token
  </button>
</div>

We have added four new buttons to the template, with each one calling out to one of the new methods we just added.

So far, we have not added anything related to interceptors, but rather just set up our application to demonstrate various things related to the interceptors and how we might be able to use them in our application. Let’s create our interceptor now. Sadly, the Angular CLI does not yet support generating the skeleton of the interceptor, so we will do it manually. Create a file at src/app/services/stock-app.interceptor.ts with the following content:

import {Injectable} from '@angular/core';
import {HttpEvent, HttpInterceptor, HttpResponse} from '@angular/common/http';
import {HttpHandler, HttpRequest, HttpErrorResponse} from '@angular/common/http'

import {Observable} from 'rxjs/Observable';

@Injectable()
export class StockAppInterceptor implements HttpInterceptor {   

  constructor() {}

  intercept(req: HttpRequest<any>, next: HttpHandler):
      Observable<HttpEvent<any>> {   
    console.log('Making a request to ', req.url);
    return next.handle(req);    
  }
}

Implement the HttpInterceptor interface

Implement the intercept API

Continue the chain by calling handle with the request

We have a mostly straightforward StockAppInterceptor class that implements the Angular HttpInterceptor interface. This interface provides one method, intercept, which we implement in the class. The intercept method is called with two arguments, the HttpRequest and an HttpHandler.

A good way to think of HttpInterceptor is that it is a chain. Each interceptor is called with the request, and it is up to the interceptor to decide whether it continues in the chain or not. Within this context, each interceptor can decide to modify the request as well. It can continue the chain by calling the handler provided to the intercept method with a request object. If there is only one interceptor, then the handler would simply call our backend with the request object. If there are more, it would proceed to the next interceptor in the chain.

Let’s hook up this simple interceptor, which at this point simply logs all outgoing requests to the console, to the application. We do so in the AppModule (available in src/app/app.module.ts) as follows:

/** Skipping other standard imports for brevity **/
import { HttpClientModule, HTTP_INTERCEPTORS } from '@angular/common/http';
import { AuthService } from './services/auth.service';
import { StockAppInterceptor } from './services/stock-app.interceptor';

@NgModule({
  declarations: [
    /** Skipping for brevity **/
  ],
  imports: [
    /** Skipping for brevity **/
  ],
  providers: [
    StockService,
    AuthService,
    {
      provide: HTTP_INTERCEPTORS,
      useClass: StockAppInterceptor,
      multi: true,
    }
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }

The major focus is on the last element in the providers section, which is how we provide the HttpInterceptor. Here, we are using the basic form of a provider, where we mention what we are providing (using the provide key), how to provide it (using the useClass, which points at our newly created StockAppInterceptor), and the fact that it is an array of interceptors (multi: true takes care of this). We can similarly add another entry for each interceptor we want.

Now we can run this application (using ng serve --proxy-config proxy.conf.json, after making sure our Node.js server is running). When you run this, open the console in your developer tools and you should see a log entry each time a server call is made. You can trigger more server calls by clicking the Refetch Stocks button.

Now, let’s extend to make the interceptor nontrivial. Modify the src/app/services/stock-app.interceptor.ts file as follows:

import {Injectable} from '@angular/core';
import {HttpEvent, HttpInterceptor, HttpResponse} from '@angular/common/http';
import {HttpHandler, HttpRequest, HttpErrorResponse} from '@angular/common/http'

import {Observable} from 'rxjs/Observable';
import 'rxjs/add/operator/do';

import { AuthService } from './auth.service';

@Injectable()
export class StockAppInterceptor implements HttpInterceptor {

  constructor(private authService: AuthService) {}

  intercept(req: HttpRequest<any>, next: HttpHandler):
      Observable<HttpEvent<any>> {         
    if (this.authService.authToken) {      
      const authReq = req.clone({
        headers: req.headers.set(
          'Authorization',
          this.authService.authToken
        )
      });
      console.log('Making an authorized request');
      req = authReq;                       
    }
    return next.handle(req)                
        .do(event => this.handleResponse(req, event),
            error => this.handleError(req, error));
  }


  handleResponse(req: HttpRequest<any>, event) {   
    console.log('Handling response for ', req.url, event);
    if (event instanceof HttpResponse) {
      console.log('Request for ', req.url,
          ' Response Status ', event.status,
          ' With body ', event.body);
    }
  }

  handleError(req: HttpRequest<any>, event) {      
    console.error('Request for ', req.url,
          ' Response Status ', event.status,
          ' With error ', event.error);
  }
}

Implement the intercept API

Check for presence of auth token in the service

Change the request to an authorized request with extra headers

Call the handle API on the request to proceed in the chain

Handle any successful response

Handle any error

We have changed a few things of note in the interceptor now:

• First, we check for the presence of the authToken in the AuthService. If it is available, we then modify the request to add an Authorization header with the current value from the AuthService.

• We have added an operator to Observable using the import 'rxjs/add/operator/do'; statement. We then use this on the next.handle.

• The do operator on an observable allows us to hook onto the results of an observable in a pass-through manner, but still make changes or have side effects. It is useful for cases like these where we want to see the response and possibly even make changes to it or log it.

• We subscribe to both the success and error events on the observable, and add the appropriate logging in both.

Now when you run your application, take the following actions:

1. See the initial request to get the list of stocks in the network inspector. Ensure that there is no Authorization header in the request.

2. Click the Set Auth Token button. Now click the Refetch Stocks button. Notice that the Authorization header is now set and sent in the request. Corresponding logs will also be printed.

3. Click Reset Auth Token to ensure that header is removed and try Refetch Stocks once again.

4. Click the Make Failing Call button and ensure that the error handler in the interceptor gets called and the logs are correctly printed.

The finished code is available in chapter9/interceptors.