Description of angular official documentation singleton service
Don’t talk about the singleton model. Those who understand the design model know it. If you really don’t understand it, you can use Baidu.
(Explain the naming of angular. angular is angular2+, angular1 is called angularjs. As for angular2, 3, 4, 5, and 6 are just angular versions, commonly known as angular. I hope you don’t call it wrong)
How to use singleton mode in angular services? There is a passage in the official angular documentation:
Singleton Service
The service is singleton within the scope of each injector. In any injector, at most there will be only one instance of the same service.
There is only one root injector here, and the UserService is registered in that injector. Therefore, there can only be one UserService instance in the entire application, and each class that requires the injection of UserService will get this service instance.
However, Angular DI is a multi-level injection system, which means that injectors at all levels can create their own service instances. Angular always creates multi-level injectors.
In general, I don’t know how to use the singleton model of dependency injection service. It’s very simple to figure it out. Just write an example and experiment. Below I will tell you my experiment summary to help you save some of this boring exploration time.
Experimental sample code
Service Code
import { Injectable } from '@angular/core';
@Injectable(
//{providedIn: 'root'}
)
export class SingletonServiveTestService {
private _name = "primaryName";
constructor() { }
setName (name){
this._name = name;
}
getName(){
return this._name;
}
}
My friend may have said, how could this TM be a singleton pattern? Don’t be excited, my friend, I think so too, why can TM be a singleton? However, in angular's dependency injection, there are several ways to make this code run in singleton mode.
Explain {providedIn: 'root'}, at first I thought that as long as I pass this object in, the service was provided to the submodule and subcomponent in the form of root, and then this service was a singleton. The background found that this object had no half a cent relationship with the singleton. It was just another way to introduce the service. It had no other use except this, so we will not talk about the situation where {providedIn: 'root'} is added below.
Inject code
Injection is divided into two types; the module of the experiment implements lazy loading.
The test results of the above code (the modules are all lazy to load)
These three results already represent various situations. If you want to know the results of some other situations, you can write an example by yourself or leave me a message
- In the or dependency aspect, the constructor in the component in the subcomponent and submodule is injected into the service. The performance characteristics of this service are singleton.
- Rely on this service in the lazy-loaded child, and inject this service into the constructor in the component below the module. The performance characteristics of this service are singleton.
- Depend on this service in the component constructor, and then depend on the injected service into the component's constructor. This service performance characteristics are non-singlearning.
Don't singletons all implement through static properties?
I think singleton is to maintain an instance of the property method. However, in angular, I want to use singletons to implement some data, and the entire project is generally used. According to the design pattern, the above and below codes are not standard singleton patterns, but in actual use, the purpose of singleton patterns is indeed achieved. There is an official document of angular as endorsement, so I wrote that type of singleton pattern in angular. As for the following, I call static attribute singleton pattern. The ts static attribute is compiled into normal js, which is just attributes on the constructor. The concept is high-level and the principle is low.
import { Injectable } from '@angular/core';
@Injectable()
export class SingletonServiveTestService {
private static _name = "primaryName";
constructor() { }
setName (name){
SingletonServiveTestService._name = name;
}
getName(){
return SingletonServiveTestService._name;
}
}
This experiment can show singleton characteristics in various situations
This method is a panacea, and it will be OK for a single case. Friends should be careful when writing codes, don’t be extensive. Combining the singleton implementation of the above code code, choose which method to use according to the specific usage scenario.
If you really use the singleton model, you will not use this mechanism of dependency injection of angular services. As for whether to use singleton to throw out dependency injection, it depends on the business scenario.
The above is all the content of this article. I hope it will be helpful to everyone's study and I hope everyone will support me more.