angular 6 dependency injection

JavascriptAngularTypescriptAngular CliAngular6

Javascript Problem Overview


In the latest release of Angular 6, a service is registered in a module using the providedIn property in the service metadata:

@Injectable({
  providedIn: 'root',
})
export class HeroService {}

However the documentation still also refers to registering the service in the module providers array in the module metadata just like we did in Angular 5:

@NgModule({
  providers: [HeroService],
})
export class AppModule {}

So,

  • Which method should be used to make the injector aware of the service that it should inject?
  • Will the module providers array method be deprecated?

Javascript Solutions


Solution 1 - Javascript

Basically you can use either, But as per new CLI provideIn will be automatically added while creating service

#providedIn

> There is now a new, recommended, way to register a provider, directly > inside the @Injectable() decorator, using the new providedIn > attribute. It accepts 'root' as a value or any module of your > application. When you use 'root', your injectable will be registered > as a singleton in the application, and you don’t need to add it to the > providers of the root module. Similarly, if you use providedIn: UsersModule, > the injectable is registered as a provider of the > UsersModule without adding it to the providers of the module. > > This new way has been introduced to have a better tree-shaking in the > application. Currently a service added to the providers of a module > will end up in the final bundle, even if it is not used in the > application, which is a bit sad.

For more information please refer here

Solution 2 - Javascript

As always when multiple solutions are available it depends on what you want to achieve. But the documentation gives you some directive to choose.

> Sometimes it's not desirable to have a service always be provided in > the application root injector. Perhaps users should explicitly opt-in > to using the service, or the service should be provided in a > lazily-loaded context. In this case, the provider should be associated > with a specific @NgModule class, and will be used by whichever > injector includes that module.

So basically you will use providedIn: 'root' for any services that are application wide. For other services keep using the old version.

Don't forget that on you already had the choice to provide service differently. For instance it's also possible to declare Injectable at component level (this doesn't change in V6).

  @Component({
    selector: 'app-my-component',
    templateUrl: './my.component.html',
    providers: [ MyService ]
  })

This way the service becomes available only in MyComponent and its sub-component tree.

Solution 3 - Javascript

If You are using angular 5+ developer, it will automatically create the injectable service when declared as providedIn: 'root', in this case you will not required to import the service in app.module.ts. You can directly use it in another component.

Solution 4 - Javascript

The @NgModule() and @Component() decorators have the providers metadata option, where you can configure providers for NgModule-level or component-level injectors.

The @Injectable() decorator has the providedIn metadata option, where you can specify the provider of the decorated service class with the root injector, or with the injector for a specific NgModule.

In your case, because it has been providedIn at "root" level, no need to add this again as a provider in the module.

More about Dependency Injection Here

Solution 5 - Javascript

When we use providedIn: 'root' property in @injectable we don't need to entry in the provider's array.

By using providedIn there will be beneficial for tree shakable feature.

Tree shakable feature removes unused dependency at the time of production when it is not used.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionHamed BaatourView Question on Stackoverflow
Solution 1 - JavascriptPardeep JainView Answer on Stackoverflow
Solution 2 - JavascriptJEYView Answer on Stackoverflow
Solution 3 - JavascriptPrashant View Answer on Stackoverflow
Solution 4 - JavascriptCharithJView Answer on Stackoverflow
Solution 5 - JavascriptShailendra SharmaView Answer on Stackoverflow