#native_company# #native_desc#
#native_cta#
  1. AngularJS Migration
  2. Overview
  3. Mental Model

Mental Model

In this lecture we are going to cover a way of thinking or reasoning about the AngularJS migration process. We call this a Mental Model and it is essential that you understand this concept to successfully migrate your AngularJS application.

Terminology and Practices

Before we get into it, lets have a look at some terminology and practices I will be following throughout this lecture series so that we are all on the same page.

Basic Terminology

AngularJS

refers to the legacy Angular framework. Anything versioned 1.x is AngularJS.

Angular

refers to the modern Angular framework. Anything versioned 2+ is Angular.

Entities

An Entity is any single thing in an application. This could be a filter, a pipe, a controller, a component or a service.

Name Changes

Now, lets take a look at some of the differences in terminology across AngularJS and modern Angular.

What was it called in AngularJS? → What is it called in Angular

Filters → Pipes

Controllers → Components

Directives + HTML → Components

Directives - HTML → Directives

Services/Factories → Services

Color Coding Schemes

We will be using the following color coding scheme to distinguish between the legacy and modern Angular entities.

Angular is BLUE
AngularJS is RED

Migration Concepts

3 img 001
Figure 1. Contacts application component diagram

Figure 1 is a simplified view of the AngularJS application that we are going to migrate, containing different entities such as Components, Controllers, Services and Resources.

Concept 1: Dual Booting

During the process of migration you will run both AngularJS and Angular in the same application, at the same time. We call this a hybrid application which allows entities written in both the legacy and modern Angular frameworks to co-exist and work together within the same application.

Note

The concept of Zones in Angular eliminates the need for $scope.$apply(…​) in a hybrid application.

Concept 2: Interoperability

Although entities written in AngularJS and Angular work together in a hybrid application, they do not do this directly. Instead, we have to either Upgrade (applicable for AngularJS entities) or Downgrade (applicable for Angular entities) to ensure interoperability.

3 img 002
Figure 2. Interoperability of upgraded (AngularJS) and downgraded (Angular) components

  • An upgraded AngularJS entity will work with other AngularJS entities as well as Angular and downgraded Angular entities.

  • A downgraded Angular entity will work with other Angular entities as well as AngularJS and upgraded AngularJS entities.

Tip

Dependency injection still works! You can have the same instance of a downgraded Angular service sharing data between an Angular and AngularJS component.

Concept 3: Who’s in control?

Consider an AngularJS application with the following HTML hierarchy.

3 img 003
Figure 3. HTML hierarchy

Now, if we migrate the <card> entity to Angular, we will need to downgrade it to use it within the AngularJS <body> entity. Similarly, we will need to upgrade the AngularJS <spinner> entity to use it within the Angular <card> entity.

Tip

AngularJS is always bootstrapped first and owns the bottom most view. This makes the root component always AngularJS.

The Plague

I like to think of the migration process as an infection or disease, gradually taking over an AngularJS application. The “disease” in this case is of course, Angular. Consider the application shown in Figure 4.

3 img 004
Figure 4. Application component diagram with downgraded Resource entity

  1. We can first “infect” the Resource entity with Angular. To maintain compatibility, we will need to downgrade the Resource entity.

Tip

Start at the leaves and always favor downgrading Angular components over upgrading AngularJS components to maintain compatibility.

  1. Next, we convert the Service entity to Angular while downgrading it to maintain compatibility with it’s child entities.

3 img 005
Figure 5. Application component diagram with downgraded Service entity

Note

The downgraded Resource entity can now be reverted back to Angular as it’s dependent component(s) have been converted to Angular.

  1. This process is then repeated throughout the application (from leaf upwards) until all components are migrated to Angular.

Caveats

  • Filters in AngularJS cannot be migrated and will have to be re-written as Pipes during the migration process.

  • Some directives (those without templates) will need to be re-written as Angular Directives.

Summary

  • The concept of Dual Booting allows entities written in both AngularJS and Angular to co-exist and work together within the same application.

  • Interoperability of entities written in AngularJS and Angular is supported via upgrading or downgrading.

  • Start at the leaves of the application and favor downgrading of entities over upgrading during the migration process.

  • Some entities such as Filters and some directives will need to be re-written as Angular entities during the migration process.

Caught a mistake or want to contribute to the book? Edit this page on GitHub!


Advanced JavaScript

This unique course teaches you advanced JavaScript knowledge through a series of interview questions. Bring your JavaScript to the 2021's today.

Level up your JavaScript now!