Migration to an AngularJS application – Refactoring to TypeScript and Angular5

Modern, web-based applications are programmed with JavaScript alongside HTML5 and CSS3. In recent years, several JavaScript frameworks have established themselves for the development of software in the web environment. In addition to the Angular framework, version 5, used here, there is also React, Ember.js and Vue.js, which are similarly popular and widespread. All these frameworks have in common that they can be used for enterprises due to their development state as well as the underlying drivers such as Google or Facebook.

Starting position

The starting position is a front-end application which was written in AngularJS, the predecessor of Angular. This should now be renewed and raised to the current successor version Angular5. With this migration, the application is to be kept viable for the future, because AngularJS will not be developed further and Angular in its current version 5 is the successor.

Differences

In AngularJS it was not yet common to build the app with TypeScript. Native JavaScript was mainly used here for programming. Now, one definitely wants to benefit from an abstraction language such as TypeScript in order to achieve a strong typing. This creates a much greater stability in the system and sets the basis for an object-oriented development. An important difference in Angular5: the focus is on dependency injection and encapsulation in components.

import { Component, OnInit, EventEmitter, ChangeDetectorRef } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs/Observable';
import { catchError, map, debounceTime, switchMap } from 'rxjs/operators';
import { of } from 'rxjs/observable/of';

@Component({
  selector: 'app-data-filter',
  templateUrl: './data-filter.component.html',
  styleUrls: ['./data-filter.component.scss']
})
export class DataFilterComponent implements OnInit {

  // start example code
  githubAccount: any;
  items = [];
  typeahead = new EventEmitter();

  constructor(private http: HttpClient, private cd: ChangeDetectorRef) {
    this.typeahead
      .pipe(
        debounceTime(200),
        switchMap(term => this.loadGithubUsers(term))
      )
      .subscribe(items => {
        this.items = items;
        this.cd.markForCheck();
      }, (err) => {
        console.log('error', err);
        this.items = [];
        this.cd.markForCheck();
      });
  }

  ngOnInit() { }

  loadGithubUsers(term: string): Observable<any[]> {
    return this.http.get('https://api.github.com/search/users?q=${term}').pipe(
      catchError(() => of(({ items: [] }))),
      map(rsp => rsp.items),
    );
  }
  // end example code

}

Approach for migration

The basis for the migration is an AngularJS application with native JavaScript without components. This still relies on the MVC structure with controllers and views. In addition, template directives were used, which are no longer available in Angular5.
All view / controller constructs as well as directives with own templates must be transferred in individual components for a migration.
With this initial situation, the decision was made to not implement a gradual migration in which both frameworks are installed and operated in parallel. We have opted for the complete rebuild of the application and will rebuild module by module.

Important steps and adjustments

First, one should think about the structure of the project. The previous structure of the app already provides a lot, however, new approaches such as lazy loading are added, which also require some structurally new conditions. Code that should be used in all future models, is usually moved to a shared folder. Each module is allocated its own folder and components, classes and services, which are only needed within the module. This way, feature modules can be loaded separately and on demand.
As already described, all controllers and views need to be transferred into the components. A new approach from Angular5, the so-called Angular CLI (Command Line Interface) assists us here. This allows for very quick development of new components, services and modules, without the need for the redundant work of writing the basic structure of the classes etc each time by hand.

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

@Component({
  selector: 'app-potential-sales-table',
  templateUrl: './potential-sales-table.component.html',
  styleUrls: ['./potential-sales-table.component.scss']
})
export class PotentialSalesTableComponent implements OnInit {

  constructor() { }

  ngOnInit() {
  }

}

The Angular CLI is also perfectly suited for controlling the build system (Webpack). A node server can be started very easily, which packs the application, compiles it and provides it in the browser.
A great and important difference is the use of the Observable pattern in Angular5. These replace in large parts the familiar promises from AngularJS. The observables enter the Angular framework with the library RxJS for Reactivity. The use of RxJS makes the communication with the interface very easy and much more convenient. However, migration is not that trivial as the concepts of promises and observables differ. A promise is executed immediately, whereas the execution of an observable only starts with .subscribe().

Summary

The migration from AngularJS to Angular5 is a step which needs to be implemented for the security and updatability of software. There are various approaches for this. For example, the Angular documentation page describes a migration with a dedicated migration pack. However, this assumes that one has already worked with components or that components are being created with the existing code, before a migration to Angular 5 takes place. This seems more cumbersome than building a complete independent new Angular5 project. In addition, you immediately have an executable app based on TypeScript and with Webpack as the basis. Furthermore, the structure can also be redesigned, which means you only have to pay limited attention to old code and old structures.
The effort for a migration is not to be underestimated, however, it can be processed in a solid framework with good planning.

Author: Christoph Riedl

Read now