Create Multiple Angular Service Instances

Instructor: [00:00] Here, we have our app component, which is this one here and you can see it visualized here, which includes here a person edit component. If we take a look at that one, it gets here a person service in its constructor. It visualizes a person here, which it gets from the person service.

[00:18] It has an input field which allows us to write in the name, and then it invokes that setPerson method, which then calls on the person service to setPerson method, which simply changes that name. As you can see, if I write here Thomas and I save it, you can see it changes.

[00:35] What's interesting is that in that app component, we have also an app child component. That app child component does similar things as that person edit component. It simply again imports that person service, getPerson, via its constructor and it visualizes it.

[00:51] You may have already noted that if I change this here and I save, both of them are in sync. The reason for that behavior is because once we register our service, in this case the person service, in our Angie module on the provider section, it is globally available on our application, and it is a single instance.

[01:10] Whenever we add components, and we then inject that person service in those components, we will get always that same instance of that person service.

[01:19] Consider we want to change that kind of behavior. For instance, here in our child component, let's add that app person edit. You can see, you get this page here below. Consider that we want for that child component and all its children, in this case the person edit component, to have a different instance of that person service, and not the global one.

[01:42] Luckily, this can be achieved by simply providing here in the providers property of the component, that same person service.

[01:53] With that, we're telling the Angular dependency injector, whenever that component wants an instance of that person service, first look it up on your own injector, which would be the definitions inside here, and then only go ahead and then span the injector to find that service.

[02:12] The fact here is if we save here and we change that name, you can see it just changes now at the very global person service which is still available here in our app component, but inside the child component, this is another person service, so the setName method won't have an effect in this one.

[02:30] Similarly also, if we now change that person's name here from that app person edit, which is included in that app child, that will get us that person service here. If I write here Katy and I save, you can see it has just an effect on that subtree of our component tree here.

[02:49] We can see now that this person service's lifetime is bound to that component tree. That also means that if I go to the app component here, and let's say here child visible, which is true, and I add here an Angie if, that component will only be visible if this flag here is true.

[03:13] Let's here add a button to toggle that flag. Now you can see I changed here name on both. It will change just on app component, as we expect. I write here Katy. I toggle that component, I re-visualize it, and you will see we get again the initial value which is saved in that app person service, [inaudible] in this case.

[03:38] It demonstrates that the instance gets destroyed of that person service, and you get a new, fresh instance once that component comes to life again.

[03:46] This hierarchical dependency injector feature of Angular is a really powerful one as it allows you to create caching services for a certain subtree of your component. As long as they are alive, they can then cache the data among them, and once they get destroyed, also the cached data will get destroyed.