Today, we will discuss the importance of Angular dependency injection provider objects in an Angular application and how to use different Angular dependency injection provider objects in different situations.

Let us try to understand this with a real-life application use case.

Use Case

In our Angular application, we have an Angular service class app-service.ts. It has a few methods written inside it to serve a designated functionality.

This class is provided at the root component level app.module.ts to make it available to all the feature modules.

For example:

@NgModule({
declarations: [ AppComponent ],
providers: [ AppService ],
})
export class AppModule { }

Let’s assume this service is used inside 1000 different application components, as the applications get bigger to serve the data respective to each component.

For example:

export class AppComponent implements OnInit {

constructor(private service: AppService){}
}

After a point in time, we decided to write a different version of this service as app-service-v1.ts with major changes in the existing method functionalities but with the same method signature.

Problem

Now, we want this new service to be implemented in all the places where app-service.ts is present.

Also, we don’t want to discard the older version as we might have to switch back to the older version if the project requires this at any later stage.

Well, how do we do it?

Any thoughts?

Solution

1. One way to approach this

If we are thinking about importing the new service app-service-v1.ts at the root level and making the changes at each component level, we must remember we have 1000 places to incorporate these changes and this number can be higher depending on the application size.

But what if we are asked to switch back to the previous version when we are done migrating to the latest version?

For example:

Previous version:

export class AppComponent implements OnInit {

constructor(private service: AppService){}}

Latest version:

export class AppComponent implements OnInit {

constructor(private service: AppServiceV1){}}

2. Another approach: Angular dependency injection providers

In this case, the root level module would look as follows:

@NgModule({

declarations: [ AppComponent ],
providers: [{ provide: AppService, useClass: AppServicev1}],
})
export class AppModule { }

With this, we complete migration to the new service.

It’s kind of like: I will keep asking for AppService, but you provide me with AppServicev1.

Angular Provider Object Literal brings a lot of variety in how we want to receive an instance of a service class inside our component.

Two of Angular’s popular dependency injection providers are:

1.    Alias provider (as described above).

2.  Value providers.

Sometimes it is more useful to have a dummy object or a ready-made object to be provided instead of an actual service instance.

This technique is commonly used in writing unit-test for our application where we do not want to use the actual service methods for testing, which may make a real-time HTTP call to our back-end service.

Unit-test module example:

describe(‘TestLoginService’, () => {

let service = {
login : ()=> of({})};
beforeEach(() => {
TestBed.configureTestingModule({
providers: [{ provide: LoginService, useValue: service }]
imports: [HttpClientTestingModule] }); }); });

I hope this article helps in enhancing your understanding of Angular dependency injection providers.

Originally published by DLT Labs at medium.com

============================================================

Thanks for reading :heart: If you liked this post, share it with all of your programming buddies! Follow me on Facebook | Twitter

Angular 8 Pagination Example and Tutorial

Angular 8 + Spring Boot 2.2: Build a CRUD App Today!

Angular 8 Forms Tutorial - Reactive Forms Validation Example

Angular 8 Tutorial By Example: (REST API, HttpClient GET, Components, Services & ngFor)

#angular #web-development