Discover Angular's core concepts and advance to building a complete SPA. Gain hands-on experience by creating modules, components, forms, routing, and APIs in an e-commerce app.

angular_setup.tar.gz

angular

In this course, you will cover the most fundamental concepts of Angular, a popular JavaScript framework. You will learn everything about building a complete Angular app, setting up the development environment, and building your own single-page application (SPA).

You’ll start off by covering the basic building blocks of Angular such as modules, components, and directives. After that, the course will introduce you to some more advanced material that focuses on forms, routing, and dealing with APIs. 

By the end of this course, you will have gained hands-on experience by building a fully functional e-commerce application.

A Hands-on Guide to Angular

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 the`app-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:**

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 the`app-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:**

Course Overview

Introduction to the Framework

Building Blocks of Angular

Basic Concepts in an Angular Application

Forms in Angular

Routing in Angular

Services and Dependency Injection

Dealing with APIs

Implement the Above in a E-commerce App

Login and Authentication

Summary and Resources

Lazy Loading of Routes