This article mainly introduces the life cycle and delay processing in the ANGULARJS, which is the core content of Angularjs, and the friends who need it can refer to
Here, we discuss some of the most advanced control-reversal containers (inversion-containers): Deferred loading (lazy-loading), Lifecycle Management (lifetime management), and deferred creation/processing ( Deferred creation/resolution).
Deferred loading (lazy-loading)
Deferred loading is the instantiation of an object when you need it. Many dependency injection systems create components as a dependent project at the outset. Sometimes, though, you don't want to instantiate these components until you use them in your application. A good example of angular is when you set up an action when you configure it, and that behavior references some components that have not yet been created.
Suppose you want to intercept the $log service built into the system, so you put it in $rootScope. Of course I do not recommend this, but this example is relatively simple and effective. In order to intercept, you use the $provide at the time of configuration and then call the cosmetic method. If you want to quote $rootScope directly, you will get an exception because of the circular reference. The solution is to load $rootScope by $injector delay.
The following code is only loaded when the $rootScope is first used.
$provide.decorator(, [, ,
($delegate, $injector) {
log = $delegate.log.bind($delegate);
$delegate.log = (msg) {
rs = $injector.get();
(rs.logs === undefined) {
rs.logs = [];
}
rs.logs.push(msg);
log(msg);
};
$delegate;
}]);
Subsequent calls will get the same single example $rootScope. Here is a usable example. I seem to have heard a (wrong) story before (angular only supports the single case) ... Of course it's not true. The approach in $injector is to give you the life cycle of managing your components.
Life Cycle Management
The lifecycle involves how you manage instances of components. By default, when you inject a angular dependency, dependency injection will help you create a copy of it and reuse it in your application. In most cases this is exactly what we are looking for. In some cases, multiple instances of the same component are required. Suppose the following count service:
Counter($log) {
$log.log();
}
angular.extend(Counter.prototype, {
count: 0,
increment: () {
.count += 1;
.count;
}
});
Counter.$inject = [];
app.service(, Counter);
Your application is to track different counters. And after you inject the service, you always get the same counter. Is this a angular restriction?
Of course not. Once again, you can create a new copy at any time by $injector service. The following code uses two separate counters:
app.run([, , ,
(rs, c, i) {
rs.count = c.count;
rs.update = c.increment;
rs.update2 = () {
c = i.instantiate(Counter);
rs.count2 = c.count;
rs.update2 = () {
c.increment();
rs.count2 = c.count;
};
};
}]);
You can see that the counters are tracked by independent instances, and here is an example. If you need to generate new instances frequently, you can register services like this:
app.factory(, [,
(i) {
{
getCounter: () {
i.instantiate(Counter);
}
};
}]);
It is so simple to produce an instance of need, and you can use your factory components instead of $injector:
app.run([, ,
(rs, cf) {
c1 = cf.getCounter(),
c2 = cf.getCounter();
rs.count = c1.count;
rs.update = c1.increment;
rs.count2 = c2.count;
rs.update2 = () {
rs.count2 = c2.increment();
};
}]);
You can take a look at this full version of the available examples. As you can see, using angular built-in dependency injection is entirely possible to manage the lifecycle of your component. What about deferred processing (deferred resolution)-for example, some components you need to be introduced after angular have been configured and need to be packaged with their dependencies.
Deferred processing (Deferred resolution)
We have introduced a way to defer processing of dependencies in angular. When you want to wrap something, you can invoke the instantiate of the $injector service, and then it can solve the dependency through the parameter sniffing, which looks like a static property of the $inject, or it can be done by checking the array you passed to it. In other words, the following is a completely effective way of writing:
|
$injector. Instantiate ([' dependency ', constructor]); |
You can also invoke a method with an ornamental array. Suppose you have a method that relies on the $log service, and you can invoke it by delaying processing at run time, as follows:
myFunc = [, ($log) {
$log.log();
}];
$injector.invoke(myFunc);
You can take a look at this available example (open your console and see what happens when you press the button).
Summarize
To sum up, angular's dependency injection offers a number of advanced features that you would expect and often use on commercial application lines. Factories, services, and providers make it easy for angular developers to take the illusion that only the only option is available. And the magic is that $injector service, you can use it to generate the required single example, create a new component or dynamically reference a dependent method.
The last thing to note is that the injection inside your client code is available even outside of angular. Let's look at an example of a wrapper outside the angular, by injecting a call $log service, Dot here. Why put ' ng ' in an array of methods? It is the core module of angular, which is implicitly added when you wrap your module, but if your instructions are to generate your own injection instances, you must explicitly add them.