Hello, everyone, and welcome back.
The last lesson we wrote, our own provider for the cause is service dependency, and we have defined
here a unique injection token.
Now, notice that normally we don't need to write these functions or provide injection tokens.
It all works in a much simpler way.
So let's see exactly what Engelhard is doing under the hood when we are not using the inject decorated
or manual profiler's.
So how does Angela know, for example, what dependency to inject here without using here to inject
liquor there?
Because our previous version of the program worked fine without it?
Well, the answer is very simple.
What's going on is that angular supports as injection tokens, class names.
So we here in the provide function if instead of creating here a manual injection token, we specify
here the name of the class.
These will also work as a unique identifier for a dependency.
Let's try this out.
If we reload here, the application, we're going to see that everything is still working as expected.
So this is one of the key features of the angular dependency injection system.
It's possible to identify dependencies using class names as a unique identifier.
It's possible to use a class name as a dependency injection token because the last name exists at runtime
under the form of a constructor function.
On the other hand, we would not be able to use an interface as an injection token.
And that's because an interface does not exist at runtime.
It's a compile time construct only.
And the other thing that we don't need to do is to write our own manual provider function.
And the reason for that is that if to the angular dependency injection system, we pass these use class
property instead of use factory and the dependencies and we specify here the name of a class in this
case causes service, then Angular knows that it needs to call the new constructor on this class and
it needs to provide the dependencies that are needed by the constructor.
So that's one thing that Angular already knows how to do.
So we don't need to write this function either.
And we can remove here the injection token.
We won't be needing it anymore.
We don't need our manually written injection token anymore because Angular internally is using the class
name as a unique identifier for the injectable.
Notice that this configuration in its current form has some redundancy.
We are using the courtesy service class on multiple places.
This can be further simplified into the following notation.
We are going to remove here the complete configuration object and we're going to pass in here only the
class name and nothing more.
With this notation.
Angular knows that this is the unique identifier of the dependency is being used as an injection token.
And also this is a constructor function that allows ANGULAR to instantiate the dependency itself.
So with this, the dependency injection system has all the necessary information for knowing how to
create here.
The course is service dependency.
Now notice the following.
So far we have been using here this provider's property of the component so each component can specify
its own provider's list.
This is not the usual way that we define application wide singletons.
Usually we define them here at the level of the application module.
So let's learn exactly what does it mean for dependency to be creative, the level of a given component.
Let's talk about hierarchical dependency injection.
This is coming right up in the next lesson.