All About Multi-Provider Feature of Angular Version 2.0

       0

We aggregate and tag open source projects. We have collections of more than one million projects. Check out the projects section.

Image Source

The newly introduced concept of dependency injection in Angular version 2.0 makes it an attractive front-end technology all because of one amazing feature called 'Multi-Providers'. In general, it allows the users to attach certain operations by themselves and a few plugin custom functionality which is not required in our mobile app use case.

In this article, we are taking a look at what the multi-providers look like, how they function and how Angular takes advantage of it to keep the platform extendible and flexible.

What is a Provider?

A provider is an instruction that depicts how an object is created for a certain token. For instance - You need to have a DataService dependency in an Angular component which looks like this:

 import {DataService} from './data.service';

 @Component (...)

 Class AppComponent {

    constructor (dataService: DataService) {

          //dataService instance of DataService == true 

     }

 }

You need to import the type of dependency and annotate a dependency argument with it. After this, Angular is well aware of how to create and inject an object of DataService type according to the provider. This can only happen when the application module is bootstrapping your app or in the component by itself. This way you have various implications regarding the availability and life cycle of the dependency.

 // application module 

 @NgModule ({

    ...

    providers: [

      { provide: DataService, useClass: DataService }

   ]

 })

 

 // or in component 

 @Component({

    providers: [   

      { provide: DataService, useClass: DataService }

    ]

 })

  class AppComponent {}

Henceforth, Angular knows how to create objects when you ask for a dependency of type DataService. Basically, there is a shorthand syntax for which we can make use of the useClass instruction to add the same value as of the token in a particular manner:

 @NgModule({

   --

   providers: [DataService]

 })

 //or in component

 @Component{(

    providers: [DataService]

 })

 class AppComponent {}

What are multi-Providers?

Basically, with the help of multi-providers, you can provide multiple dependencies for a single token. Let us take an instance of how it looks like. The below-given code creates an injector with the multi-providers as given.

  const SOME_TOKEN: Opaque Token = new Opaque Token('Some Token');

  var injector = injector.create ([

     { provide:SOME_TOKEN, useValue: 'dependency one', multi: true},

     { provide:SOME_TOKEN, useValue: 'dependency two', multi: true}

  ]);

  

  var dependencies = injector.get(SOME_TOKEN); 

  //dependencies = ['dependency one' , 'dependency two' ]

It should be noted here that the users need not create manual injectors and henceforth while creating Angular applications, the platform itself takes care of the same. Due to this reason, it is only used for demonstration purposes.

A token can be a string or a type. We utilize the strings with the goal that we don't take classes to speak to a string an incentive in DI. Yet at the same time, to avoid the blunder messages in the event that something turns out badly, at that point we can likewise make a string token by utilizing OpaqueToken. We do not need to worry about this as the most interesting part of it is to register our providers using the multi: true option. By making use of multi: true, it instructs Angular that the provider is a multi-provider and can offer multiple values for a single token in DI. That’s what we want to do. We have two providers and both have the same tokens with the multiple values. At the point when we request a dependency on a token, we get a total rundown of all the enlisted and given values.

You may get a question like why should we provide multiple values for a single token? All things considered, when we register various suppliers with a similar token, the last one successes. For instance - take a look at the given code where only TurboEngine is getting injected as the provider is registered at the last.

class Engine {}

class TurboEngine {}

var injector = injector.create ([

   { provide: Engine deps: [] },

   { provide: Engine, useClass: TurboEngine, deps: [] }

]);

var engine = injector.get(Engine); 

// engine instance of TurboEngine

This indicates that with the help of multi-providers, you can extend the extended thing for any particular token. Also, Angular makes use of such a mechanism for providing pluggable hooks. One of these hooks, for example, are validators. While making a validator, you have to add it to the NG_VALIDATORS multi-supplier as and when required.

@Directive ({ 

  selector: '[customValidator][ngModel]';

  providers: [

    provide: NG_VALIDATORS,

    useValue: (formControl) => {

      // validation happens here 

    }.

    multi: true

   ]

 })

 class customValidator {}

multi-suppliers can't be blended in with the typical suppliers and this bodes well as we can broaden or abrogate a supplier for a token. The Angular stage accompanies a few more multi-suppliers to broaden them without custom code.

TakeAway

multi-providers turn out to be a decent feature for implementing a pluggable interface which is extensible from anywhere. The ultimate disadvantage of multi-providers is that it is only as powerful as the platform provides it. Both the NG_VALIDATORS and NG_ASYNC_VALIDATORS can be actualized straightforwardly into the stage. There is no other way to introduce our own custom multi-providers which depicts what the platform does and this is also not needed. Till then - keep learning!