Lazy Loading of Routes

Let’s go inside our project and run npm start on the command line to see what all files it builds.

npm start

Now let’s take a close look at the files that have been built and try to understand what they are for.

The main.js file contains all the code in our application, the polyfills.js file loads all the polyfill scripts to make sure it is compatible with all the modern browsers. The runtime.js loads all the other files. The styles.js file loads the styles as the name suggests, and then the vendor.js file loads all the imported libraries. 
Also, have a look at the sizes of these files that we will compare with the production generated files.

Now lets us run our application in production mode using:

Use :

ng serve -o --prod

Look at the generated files now, they are less in number, and smaller in size too . Where did the vendor.js bundle go? So the imported libraries are now inside the main.js bundle, and the compilation process during the build does Ahead-of-Time compilation (AOT) that loads the HTML and TypeScript code into JS files. This will render the application faster on the browser, and the compiler does not need to be inside the bundle. The request would not need to load all the files from the server now that will improve the start-up time of our application.

The main purpose of lazy loading is, therefore, to reduce the size of the only large-sized file now, which is main.js. We do that by lazily loading the files that are required occasionally.

Working with lazy loading

To start with lazy loading to asynchronously load the feature module for routing whenever required, we go to the route configuration and use the property loadChildren.

Let’s see what this property does.

 {path: 'user', loadChildren: './users/user.module#UserModule'},

The loadChildren property is not something related to the children property that we saw in Child Routes. This property is only used for lazily loading the feature module.

Let’s break down what the property’s value means. The loadChildren property accepts a string value that contains the route to the feature module followed by a hash symbol and then the name of the feature module.

Now, when the route gets activated, this loadChildren property will get activated and load the requested module. It will then load the requested component and display that component’s template.

canLoad guard

So, the first thing about the canLoad guard clears its meaning from its name itself. This guard tells it to load a particular module only if it can be loaded.

This means that check the criteria before loading the module, otherwise, there is no need to load this module if the requirements are not met. This secures our application from the users who do not have the access to view a particular component template.

So in case, we do not want the module to be loaded, we use canLoad guard, authorize the user, if successful, move to loading the module then.

To create this guard, as we have seen earlier, we will import it inside a service. import {CanLoad} from ‘@angular/router’; This canLoad guard also has a route property.

canLoad(route: Route): boolean {
   return this.method(route.path);}

Put this guard inside the route configuration now.

{ path: 'user', canLoad: [AuthGuard], loadChildren: './user/user.module#UserModule'}}

Now after loading the page, it redirects to the guard, and there if you see the files loaded inside the network tab of the console, you will see that the module has not loaded yet. It will load only once the authorization of the user is complete.

Now, if we cancel the authorization, the file would not need to load, and if the authorization completes, it will load the bundle file after that then.

Preloading modules

• Preload no modules
• Preload all modules
• Custom preloading strategy

In the code demo below, run the app and open the developer console, go to network tab and observe the lazy loading of data on change of routes.

Focus on the lines 7-11 of theapp-routing.module.ts file.

The following images show how a non-lazy loaded route shows up in the developer console compared to a lazily loaded route.

Non-lazy loaded route: