Angular

Question 1

order of import statements for Routing modules to work should be considered carefully

Answer 1

angular registers all the routes in the order of the import statements,
if there is wild card or '' in the initial module all the routings for the modules that are declared later will not work

All the feature routing modules should be imported before the AppRoutingModules

To fix this all we have to do is, change the import order of the modules in the AppModule. Import EmployeeModule before AppRoutingModule as shown below.

@NgModule({
  declarations: [
    AppComponent,
    HomeComponent,
    PageNotFoundComponent
  ],
  imports: [
    BrowserModule,
    EmployeeModule,
    AppRoutingModule,
    HttpClientModule,
  ],
  providers: [EmployeeService],
  bootstrap: [AppComponent]
})
export class AppModule { }

Question 2

have page not found component template for wild card route path’**’

Answer 2

const appRoutes: Routes = [
{ path: ‘home’, component: HomeComponent },
{ path: ‘’, redirectTo: ‘/home’, pathMatch: ‘full’ },
{ path: ‘**’, component: PageNotFoundComponent }
];

Question 3

core module services should be singleton, so the module needs to be imported only once in the app-module

Answer 3

core module services should be singleton, so the module needs to be imported only once in the app-module

Question 4

browserModule should be imported only once in the app-module

Answer 4

browserModule should be imported only once in the app-module

Question 5

use forchild for routes in the features modules and forRoot only once in the app-module

Answer 5

use forchild for routes in the features modules and forRoot only once in the app-module

Question 6

Shared modules should not have providers

shared modules should not import or re-export Modules have providers

Answer 6

lazy loaded modules creates their own branch on the dependency injection tree

if a lazy loaded module imports the shared module, we endup with more than one instance of service provided by the shared module

Question 7

The SharedModule may re-export other common angular modules, such as CommonModule, FormsModule, ReactiveFormsModule etc. Instead of writing the same code in every feature module to import these commonly used Angular modules we can re-export them from a SharedModule, so these commonly used Angular Modules are available to all the feature modules that import this SharedModule.

Answer 7

The SharedModule may re-export other common angular modules, such as CommonModule, FormsModule, ReactiveFormsModule etc. Instead of writing the same code in every feature module to import these commonly used Angular modules we can re-export them from a SharedModule, so these commonly used Angular Modules are available to all the feature modules that import this SharedModule.

Question 8

The SharedModule is then imported by all the FeatureModules where we need the shared functionality. The SharedModule can be imported by both - eager loaded FeatureModules as well as lazy loaded FeatureModules. We will discuss eager and lazy loading modules in our upcoming videos.

Answer 8

The SharedModule is then imported by all the FeatureModules where we need the shared functionality. The SharedModule can be imported by both - eager loaded FeatureModules as well as lazy loaded FeatureModules. We will discuss eager and lazy loading modules in our upcoming videos.

Question 9

By default all the components, directives and pipes in a module are available only to that module; we need to have a exports array to include in other modules

Answer 9

By default all the components, directives and pipes in a module are available only to that module; we need to have a exports array to include in other modules

Question 10

if we want to share any components, directives or pipes from our shared module
we need to include them in declartions and export arrays
this makes other feature modules to use these components that are shared

Answer 10

if we want to share any components, directives or pipes from our shared module
we need to include them in declartions and export arrays
this makes other feature modules to use these components that are shared

Question 11

we could export module with without including in the imports module in the shared modules
all the modules that import the shared modules could use anything in this module like reactiveFormsModule,
CommonModule

we need not reimport the formsmodule or commonModule

Answer 11

import { NgModule } from ‘@angular/core’;
import { CommonModule } from ‘@angular/common’;
import { ReactiveFormsModule } from ‘@angular/forms’;

@NgModule({
imports: [
// At the moment we do not have any components in this SharedModule
// that require directives of CommonModule or ReactiveFormsModule
// So we did not include them here in the imports array. We can
// export a module without importing it first
],
declarations: [],
// Our Employee FeatureModule requires the CommonModule directives
// such as ngIf, ngFor etc. Similarly, Employee FeatureModule also
// requires ReactiveFormsModule directives. So export CommonModule
// and ReactiveFormsModule.
exports: [
CommonModule,
ReactiveFormsModule
]
})
export class SharedModule { }

Importing in feature module:
In EmployeeModule (employee.module.ts), remove CommonModule and ReactiveFormsModule references as these modules are now provided by the imported SharedModule.

import { NgModule } from ‘@angular/core’;

import { EmployeeRoutingModule } from ‘./employee-routing.module’;

import { CreateEmployeeComponent } from ‘./create-employee.component’;
import { ListEmployeesComponent } from ‘./list-employees.component’;
import { SharedModule } from ‘../shared/shared.module’;

@NgModule({
  imports: [
    EmployeeRoutingModule,
    SharedModule,
  ],
  declarations: [
    CreateEmployeeComponent,
    ListEmployeesComponent
  ]
})

export class EmployeeModule { }

Question 12

Grouping routes and creating component less route in angular

All the routes in an angular module that you want to lazy load should have the same route prefix.

Answer 12

we could add prefix by path and defining children property;
const appRoutes: Routes = [
{
path: ‘employees’,
children: [
{ path: ‘’, component: ListEmployeesComponent },
{ path: ‘create’, component: CreateEmployeeComponent },
{ path: ‘edit/:id’, component: CreateEmployeeComponent },
]
}
];

Code explanation :
Notice we have a parent route with path employees
The parent ‘employees’ route has 3 child routes
All the 3 child routes will be pre-fixed with the parent route path - employees
Notice the parent route(employees) does not have a component associated with it. That is why this route is called a component less route.
With the above route configuration, we have the following routes
Route Path Description
/employees Displays the list of all employees
/employees/create Allows to create a new employee
/employees/edit/1 Allows to create a edit an existing employee

Question 13

angular route paths are case sensitive

Answer 13

angular route paths are case sensitive

{ path: ‘create’, component: CreateEmployeeComponent },

Question 14

all the angular modules are lazy loaded by default

Answer 14

all the angular modules are lazy loaded by default

Question 15

How to Lazy load

Answer 15

Network tab:
11 request
4.3 MB of data transfer/downlaoded
load time 3.33s

when we navigate to feature module:
we had only one request for getting the data, as all the feature modules components, directives, pipes are already downloaded when we bootstrapped the application

Unless, you are using lazy loading, all the modules are eagerly loaded. This means, all the modules in your angular application and their associated components, directives, pipes and services must be downloaded from the server, when the user first visits the application. Depending on the number of modules in your application and the internet speed, this could take a significant amount of time and may very badly affect the end user experience.

To address this problem, we use asynchronous routing, which loads feature modules lazily, on demand. This can significantly reduce the initial load time of your application.

Question 16

Lazy loading module should not be referenced in any of the modules - not even in the app.module; else it will be eager loaded

Answer 16

right click on the module to find if there are any reference

Question 17

conditions for lazy loading

Answer 17

We want to lazily load EmployeeModule. To lazy load a module, it has to meet 2 requirements.

All the routes in the angular module that you want to lazy load should have the same route prefix

The module should not be referenced in any other module. If it is referenced, the module loader will eagerly load it instead of lazily loading it.

Our application already meets the first requirement. All our EmployeeModule routes have the same route prefix i.e employees. We discussed how to do this in our previous video.

Question 18

How to lazy load the feature module

load children - for lazy loading of the feature modules

Answer 18

remove the feature module reference in the root module
at this time as the root module does not know the reference, all the feature module routes will not work
add loadChildren-{ path: 'employees', loadChildren: './employee/employee.module#EmployeeModule' }
path - this is going to be the same route prefix path for feature module routes 
Make sure that you add the loadChildren before wild card route for appModule routes path

#EmployeeModule - this is the feature module class name 
./employee/employee.module - this is path for the feature module

Remove the prefix in the feature routing module else you might need to enter it twice in the url

const appRoutes: Routes = [
{
path: ‘employees’,
children: [
{ path: ‘’, component: ListEmployeesComponent },
{ path: ‘create’, component: CreateEmployeeComponent },
{ path: ‘edit/:id’, component: CreateEmployeeComponent },
]
}
];

const appRoutes: Routes = [
{ path: ‘’, component: ListEmployeesComponent },
{ path: ‘create’, component: CreateEmployeeComponent },
{ path: ‘edit/:id’, component: CreateEmployeeComponent },
];

Question 19

Route paths
ForRoot - for the root module, this creates a single routing service and registers routes
ForChild - this for registering routes in feature routing module, this does not create a new route service instance, instead uses the same instance that was created by ForRoot in the app module
keep in mind that we need to import first the feature module then the approuting module in the imports of appModule. else the wildcard routes in root module will override the feature module routes
Children - for having common prefix for routes in a routing module
loadChildren- for lazy loading the modules

Answer 19

Route paths
ForRoot - for the root module, this creates a single routing service and registers routes
ForChild - this for registering routes in feature routing module, this does not create a new route service instance, instead uses the same instance that was created by ForRoot in the app module
keep in mind that we need to import first the feature module then the approuting module in the imports of appModule. else the wildcard routes in root module will override the feature module routes
Children - for having common prefix for routes in a routing module
loadChildren- for lazy loading the modules

Question 20

we do not import the feature routing module directly in the appmodule; instead we import the feature routing module into feature module
the feature module is imported into the root module; where we get all the routes for feature module

Answer 20

we do not import the feature routing module directly in the appmodule; instead we import the feature routing module into feature module
the feature module is imported into the root module; where we get all the routes for feature module

Question 21

How to generate a module with lazy loading

Answer 21

ng generate module Admin –route Admin –module app.module

Question 22

Injection

Answer 22

https://medium.com/coding-blocks/power-of-angular-dependency-injection-b981faa9c0de

In “You don’t know Angular Series” today, we will explore the most interesting coding pattern which is typically used to enhance efficiency and modularity of our applications.
The services or objects which our class needs to perform its operations are called dependencies. We inject these dependencies in our classes. In Angular, these dependencies are provided to the classes at the class initialization.
In this post, we are not going to see “How DI works” but we will try to learn two powerful features of Dependency Injection which will give our applications enough modularity and efficiency.
Removing Hardcoded API Endpoints:
Hardcoded API Endpoints in a single file are some day to day Frontend problems. To explain this, let’s take an example:
I am using a third party API say /api/v1/dialogflow/. Now, the API team has changed the endpoint to api/v2/dialogflow/. Please be honest with you, how many files you are going to change for this v1 to v2 change :p
When we start writing code, we don’t realize the scalability issues. The ideal solution is to change only one file so that it can inject that dependency in all other files. But, how can we achieve this?
The solution to this problem is to learn theuseValue property inside NgModule.

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    AppRoutingModule
  ],
  providers: [
    {provide: 'api', useValue: 'api/v5/dialogflow'}
  ],
  bootstrap: [AppComponent]
})
Whatever we declare as a useValue, can be injected into the services as a variable, it means we no longer have to hardcode our variable into the services :)
To inject it into our service, we will use Inject decorator from @angular/core. Finally, we can access the Injected variable with this keyword.

import { Injectable, Inject } from ‘@angular/core’;

@Injectable()
export class MainService {

constructor(@Inject(‘api’) private api: string) {
console.log(this.api);
}

}

Here, the value of the keyprovide in the providers array of app.module.ts will be matched with the argument of Inject Decorator. The this.api logs the complete endpoint in the console asapi/v5/dialogflow.

Question 23

injection token

Answer 23

The previous method of injecting variables helps you in modularity but is not scalable. With the hardcoded provide key as api we are not allowed to use the same key with a different useValue.
providers: [
{provide: ‘api’, useValue: ‘api/v5/dialogflow’},
{provide: ‘api’, useValue: ‘api/v5/dialogversion’}
]
The code shown above is not going to work, as it refers to the same hardcoded instantiation i.e api.
We need to create an object of InjectionToken class and have to remove the hardcoded value api. In this way, we will be able to create multiple instances and can use them inside our providers array. We have written the token.ts as follows:

import {InjectionToken} from ‘@angular/core’;

export const TOKEN1 = new InjectionToken('api');
export const TOKEN2 = new InjectionToken('api');
export const TOKEN3 = new InjectionToken('api');

The InjectionToken from @angular/core helps us to achieve this as shown in the example above. We can then replace our hardcoded api in both service and module.ts files.
The TOKEN’S can be injected into the service after importing it from token.ts.
import { TOKEN1 } from ‘./token’;
import { Injectable, Inject } from ‘@angular/core’;

@Injectable()
export class MainService {

constructor(@Inject(TOKEN1) private api: string) {
console.log(this.api);
}

}

Now, we can inject all the tokens into our app.module.ts as well.
import { TOKEN1, TOKEN2, TOKEN3 } from ‘./token’;

import { BrowserModule } from ‘@angular/platform-browser’;
import { NgModule } from ‘@angular/core’;
import { AppComponent } from ‘./app.component’;

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule
  ],
  providers: [
    {provide: TOKEN1, useValue: 'api/v5/dialogflow'},
    {provide: TOKEN2, useValue: 'api/v5/docs'},
    {provide: TOKEN3, useValue: 'api/v5/contact'}
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }

Even if we have many services using the API endpoints, updating the useValue once updates the dependencies of all of them wherever the TOKEN is injected. InjectionToken helps to make the code modular without any hassle of figuring out where you have written your endpoints or variables.