Hello, everyone, and welcome back.
In this lesson, we are going to talk about Iraqi oil dependency injection we have been creating here
our Courcy service dependency by declaring here a provider at the level of the application component.
Notice that the same way that we have defined this here, the level of the top level component of our
application, we could also be clear here, another provider at the level of the course care component.
If we try results, everything is still working as expected, but something is different in order to
understand it, let's say over here to our courses service and have here some logging to the constructor.
So we are going to log here to the council, a unique identifier that uniquely identifies a given courses
service instance.
Let's define here a variable.
We are going to call it counter and we're going to initialize it to zero.
Now, each time that the constructor gets called, we're going to go ahead and increment discounted.
Now, here in the console log statement that we are about to write, we are going to write creative
courses, service, and we are going to append here the current value of the counter.
We try out this version of our application, try to guess what we're going to get here in the console
if we expected.
We are going to see that.
We have here a series of logging statements.
We can see that there is a lot of logging going on.
Let's simplify a bit here to the logging.
We are going to remove these logging statement here in our cursor component and leave only the logging
here at the level of the constructor.
So if we try this out, we are going to see that multiple instances, of course, this service were
created.
So a total of 11 instances, as we can see here.
Now, what is exactly going on here?
In order to better understand this, let's give to each coarsest service instance and identify it.
And this is going to be a number to this identifier.
We are going to assign the current value of the counter and we are going to bring this out to the screen
at the level of the cursor components.
So we assign to our ID here the counter value and we're going to remove this logging statement from
the constructor where we switch here to our cost curve component.
And we are going to quickly add back here this logging statement.
So this is the closest service at the level of the course curve and we are going to concatenate these
with the identifier of the courses service.
These will allow us to understand what caused this service instance.
Are we exactly accessing here?
So if we try these out, what do we see here in the log that each instance of the course that we have
here, several cards on the screen, we have Tinkertoys.
Each instance has its own instance of the courses service.
So there is sort of a global instance, of course, this service, which takes the value number one,
and that is the one that is being injected here, the level of the service, the rest of the instances,
two, three, four, etc., all the way until 11 are injected at the level of the cost curve.
Let's further confirm that that is indeed what is going on.
We are going to log here in the constructor of our application component, the course service instance
that we are using here.
So let's have here in our logging that this is the root component and let's append here the course service
idea.
So if we tried this out now, we are going to see that in the in the root component.
We are injecting instance number one of the courses, service class.
And then on each of the cards here in our list, we are injecting a different instance.
So we have a total of ten instances.
Of course, this service when instance is created here at the level of the root component and it's injected
directly here in the constructor that's instanced number one.
And then for each of the cards here in our culture, at least, we are creating an instance here that
is unique to each of the course cards.
And that instance is getting injected here.
So what we have here is yet our technical dependency injection we have here and hierarchy of components
we have here, the application component that is composed here of ten course card components.
Each of these components has a provider's property, so each component has its own list of providers.
Whenever a dependency is needed in a given component, the component is going to go through its providers
and it's going to try to find a provider that provides the corresponding dependency.
If the component has such a provider, then it's going to use it to create the dependency.
So that will happen here at the level of the application root component.
It needs Accorsi service.
So it's going through the list of providers.
It finds the provider for courses, service and then it.
Instantiates the glass and receives it here as a dependency, the exact same thing happens here at the
level of each Coast Guard component in order to create the component we need here.
Accorsi service dependency, the component will go through its list of providers.
It finds here a provider, and it uses it to create its own private instance that is not accessible
anywhere else on this application.
Now, the question is, what would happen if a given component would try to find a provider for a dependency
and it would not find a provider in its own private list of providers?
Let's see what would happen.
So if we were lower the application, we are going to see that indeed this application is still working
as before.
But now if we open here to the console, we are going to see that there is only one instance at the
level of the application, of course, is service.
It's the one created here in route component number one, the same instance with a V number one.
It's also being used in all the course card components we have here, 10 occurrences of the logging
of the course service with idea number one.
So what exactly happened here and how does this work?
Well, what happened is that this component here tried to find a provider for the courses service dependency
in its own list of providers.
It did not find a provider that would satisfy that dependency.
So it moved on to its parent component, in this case, the application component to see if there would
be a provider that will satisfy the dependency.
If that would be the case, then the course card component here, which is a child component of the
application component, would then take its dependency from the parent component.
So that is why this is called ineradicable dependency injection system.
It's because there is an Iraqi of injectors that follows the Iraqi of the components themselves.
So child components like the casket component will ask the parent components for their dependencies
in case the component cannot create the dependency themselves.
That will go all the way down until the root of the application.
So if there are multiple levels of components and the dependencies needed in a deeply nested component,
then that component is going to ask its multiple parent components for the dependency.
And this will go on until the root component of the application and even further down the injection
tree until the very root of the application.
This means that the Iraqi oil dependency injection system allows each component to create its own dependencies
if necessary.
Now, when is this functionality useful in the case of the courses service, the service, other than
the idea that we have created here just for troubleshooting purposes, does not really have any state.
These are stateless functions that call the back end and return the result directly.
There is no data stored here at the level of the courses service in those cases.
These multiple instances, of course, service are interchangeable.
There is no need to create multiple copies of this particular service.
We can all share the same courses service that we can make a global application.
Singleton But if, on the other hand, the service that we are injecting here does have some state that
is private to a given part of the application, then in that case we might want to define here a provider
at the level of a component and have that dependency objective and make sure that that dependency is
not visible anywhere else on the application.
Notice also that if we use a local provider at the level of a component, then the service is created
by those providers are linked to the life cycle of the component.
So when the component gets destroyed, those service instances are also removed from memory.
Now that we know how the dependency injection system works and how can we manually configure here our
providers, let's look at an alternative syntax for configuring our dependency injection system.
We're going to talk about three Shakal providers.