A singleton service is a service for which only one instance exists in an app.
\nFor a sample app using the app-wide singleton service that this page describes, see the\n
There are two ways to make a service a singleton in Angular:
\nprovidedIn property of the @Injectable() to \"root\".AppModule or in a module that is only imported by the AppModuleprovidedInlinkBeginning with Angular 6.0, the preferred way to create a singleton service is to set providedIn to root on the service's @Injectable() decorator. This tells Angular\nto provide the service in the application root.
For more detailed information on services, see the Services chapter of the\nTour of Heroes tutorial.
\nproviders arraylinkIn apps built with Angular versions prior to 6.0, services are registered NgModule providers arrays as follows:
If this NgModule were the root AppModule, the UserService would be a singleton and available\nthroughout the app. Though you may see it coded this way, using the providedIn property of the @Injectable() decorator on the service itself is preferable as of Angular 6.0 as it makes your services tree-shakable.
forRoot() patternlinkGenerally, you'll only need providedIn for providing services and forRoot()/forChild() for routing. However, understanding how forRoot() works to make sure a service is a singleton will inform your development at a deeper level.
If a module defines both providers and declarations (components, directives, pipes),\nthen loading the module in multiple feature modules would duplicate the registration of the service. This could result in multiple service instances and the service would no longer behave as a singleton.
\nThere are multiple ways to prevent this:
\nprovidedIn syntax instead of registering the service in the module.forRoot() and forChild() methods in the module.Note: There are two example apps where you can see this scenario; the more advanced forRoot() and forChild() in the routing modules and the GreetingModule, and the simpler
Use forRoot() to\nseparate providers from a module so you can import that module into the root module\nwith providers and child modules without providers.
forRoot() on the module.forRoot() method.forRoot() and the RouterlinkRouterModule provides the Router service, as well as router directives, such as RouterOutlet and routerLink. The root application module imports RouterModule so that the application has a Router and the root application components can access the router directives. Any feature modules must also import RouterModule so that their components can place router directives into their templates.
If the RouterModule didn’t have forRoot() then each feature module would instantiate a new Router instance, which would break the application as there can only be one Router. By using the forRoot() method, the root application module imports RouterModule.forRoot(...) and gets a Router, and all feature modules import RouterModule.forChild(...) which does not instantiate another Router.
Note: If you have a module which has both providers and declarations,\nyou can use this\ntechnique to separate them out and you may see this pattern in legacy apps.\nHowever, since Angular 6.0, the best practice for providing services is with the\n@Injectable() providedIn property.
forRoot() workslinkforRoot() takes a service configuration object and returns a\nModuleWithProviders, which is\na simple object with the following properties:
ngModule: in this example, the GreetingModule classproviders: the configured providersIn the AppModule imports the GreetingModule and adds the\nproviders to the AppModule providers. Specifically,\nAngular accumulates all imported providers\nbefore appending the items listed in @NgModule.providers.\nThis sequence ensures that whatever you add explicitly to\nthe AppModule providers takes precedence over the providers\nof imported modules.
The sample app imports GreetingModule and uses its forRoot() method one time, in AppModule. Registering it once like this prevents multiple instances.
You can also add a forRoot() method in the GreetingModule that configures\nthe greeting UserService.
In the following example, the optional, injected UserServiceConfig\nextends the greeting UserService. If a UserServiceConfig exists, the UserService sets the user name from that config.
Here's forRoot() that takes a UserServiceConfig object:
Lastly, call it within the imports list of the AppModule. In the following\nsnippet, other parts of the file are left out. For the complete file, see the
The app displays \"Miss Marple\" as the user instead of the default \"Sherlock Holmes\".
\nRemember to import GreetingModule as a Javascript import at the top of the file and don't add it to more than one @NgModule imports list.
GreetingModulelinkOnly the root AppModule should import the GreetingModule. If a\nlazy-loaded module imports it too, the app can generate\nmultiple instances of a service.
To guard against a lazy loaded module re-importing GreetingModule, add the following GreetingModule constructor.
The constructor tells Angular to inject the GreetingModule into itself.\nThe injection would be circular if Angular looked for\nGreetingModule in the current injector, but the @SkipSelf()\ndecorator means \"look for GreetingModule in an ancestor\ninjector, above me in the injector hierarchy.\"
By default, the injector throws an error when it can't\nfind a requested provider.\nThe @Optional() decorator means not finding the service is OK.\nThe injector returns null, the parentModule parameter is null,\nand the constructor concludes uneventfully.
It's a different story if you improperly import GreetingModule into a lazy loaded module such as CustomersModule.
Angular creates a lazy loaded module with its own injector,\na child of the root injector.\n@SkipSelf() causes Angular to look for a GreetingModule in the parent injector, which this time is the root injector.\nOf course it finds the instance imported by the root AppModule.\nNow parentModule exists and the constructor throws the error.
Here are the two files in their entirety for reference:
\nYou may also be interested in:
\n