Angular is one type of framework that is used for building single-page client applications using HTML and Typescript. Angular offers fine building accessibility and it is written in Typescript.

In this blog, we are going to learn some dependency injection particularities with Angular, also specifically in combination with lazy loaded modules in angular application. Remember, if you some things are confusing - you can always hire an Angular expert.

Angular always supports dependency injection. There are some ways of registering services in Angular.

Providing a Service

First, we create an angular application with the help of Angular CLI with the following command:

ng new demoproject

Now, we can create a service using CLI command in the root project directory. for that use the following command:

ng generate service User

This command creates the following UserService structure:

user/service.ts 
import { Injectable } from '@angular/core';
 @Injectable({ 
providedIn: 'root',
 }) 
export class UserService {
 }

Now, service is created. Thus, you can inject UserService anywhere in your angular application. It is also called a singleton service because it is a service for which only one instance exists in an application. It will tell angular application to provide the service in the application root.

The service itself is one type of class that the CLI generated and it is decorated with @Injectable() decorator. By default, in any angular application, this decorator has a providedIn property, which creates a provider for the service. In this above example, providedIn: 'root' specifies that Angular should provide the service in the root injector.

Provider scope

When we add a service provider to the root application injector, then it is available throughout the application. In addition, these providers are available to all the classes in the angular application as long they have the lookup token.

We should always provide our service in the root injector otherwise there is a situation where you want the service to be available only if the consumer imports a particular @NgModule.

NgModule providers array

In applications built with Angular versions, services are registered NgModule providers arrays as the following example:

@NgModule({
  	...
  	providers: [UserService],
  	...
})

If this NgModule acts as the root AppModule, the UserService would be a singleton instance and available all over the application. So you can see it coded this way, using the providedIn property of the @Injectable() decorator on the service itself. It is preferable as of Angular 6.0 because it makes your services tree-shakable.

providedIn and NgModules

Another way is to specify that a service should be provided in a particular @NgModule. For example, if we don’t need to UserService to be available to applications. When they import a UserModule that is created previously, so we can specify that the service should be provided in the module:

src/app/user.service.ts
import { Injectable } from '@angular/core';
import { UserModule } from './user.module';
@Injectable({
  providedIn: UserModule,
})
export class UserService {
}

The example above shows the way to provide a service in a module. This method automatically enables tree-shaking of the service, if nothing injects it, this method preferred. If it is not possible to specify in the service which module should provide it, we can also declare a provider for the service within the module. Following example shows it:

src/app/user.module.ts
import { NgModule } from '@angular/core';
import { UserService } from './user.service';
@NgModule({
  providers: [UserService],
})
export class UserModule {
}

Limiting Provider Scope by Lazy Loading Modules

In the simple CLI-generated angular application, modules are always eagerly loaded which means that they are all loaded when the application launches every time. Angular uses injector() components to make all things available between all modules. In an eagerly loaded app type, the root application injector makes all of the providers in all of the modules available throughout the angular application.

This behavior automatically changes when we use lazy loading. Lazy loading is a technique in Angular that allows you to load modules only at that time when you need particular modules. When the user navigates in the application, the modules are loaded as required. for example, when routing. They are not loaded right away like with eagerly loaded modules. This means that any services listed in their provider arrays are not available because the root injector does not know about these modules.

When the angular application router lazy-loads a module, it creates a new injector. This newly created injector is a child of the root application injector. Here we can imagine injectors as a tree pattern; in this tree, only one single root injector and many child injectors for each lazy loaded module are shown. The router adds from the root injector to the child injector to all of the providers. When the router creates a component within the lazy-loaded environment, Angular selects service instances created from these providers to the service instances of the application root injector.

Any component created within a lazy loaded in a module’s environment, like from router navigation, will get the local instance of the service, not gets the instance in the root application injector. The instance created for the application root will continue to receive components from external modules.

When you provide service as lazy loading module, then not all services can be lazy loaded. For example, some modules only work in the root module, for example, the Router. Here Router works with the global location object in the browser.

As of Angular version 9, we can provide a new instance of service with each lazy loaded module. The following code adds this functionality to UserService.

src/app/user.service.ts
import { Injectable } from '@angular/core';
@Injectable({
  providedIn: 'any',
})
export class UserService {
}

In above example with the providedIn: 'any', all modules share a singleton instance which is eagerly loaded; however, modules each get their own unique instance which is lazy loaded, as shown in the following diagram.

Limiting Provider Scope with Components

The mechanism to limit provider scope is by adding the service you want to limit to the component’s providers array. Component providers and NgModule providers are conventional of each other. This method is useful when you want to eagerly load a module that needs a service all to itself. Providing service in the component limits the service only to that component and its successor. Other components in the same module cannot access it.

src/app/app.component.ts
@Component({
/* . . . */
  providers: [UserService]
})

Conclusion

In this blog, we have learned angular services, providedIn and Lazy Modules. Different ways of registering Angular services how to use the providedIn or NgModule.providers. also see the bundling impact, in that providedIn allows to tree-shake out Angular services that are not being used. So in general always recommend the providedIn to use as the default.

Author Bio


Ajay Patel – Technical Director, iFour Technolab Pvt. Ltd. A Seasoned technocrat with years of experience building technical solutions for
various industries using Microsoft technologies. With sharp understanding and technical acumen, have delivered hundreds of Web, Cloud, Desktop and Mobile solutions and is heading the technical department at iFour Technolab Pvt. Ltd.