Hello, everyone, and welcome back in the U.S., we are going to do a deep dive on the angular dependency
injection system.
The dependency injection is a critical part of the angular ecosystem.
We have been using it so far here.
For example, we are injecting the courses service directly here in our application component.
This is what dependency injection looks like.
Any dependencies that are given class has such as, for example, a component or a directive can be
injected directly via the constructor.
So the component class itself does not know how to create its dependency.
The this service dependency is provided to the class via the constructor.
A dependency class such as for example, the courses service class can also have its own dependencies
injected in the constructor and so forth.
These dependency injection system has multiple advantages.
For example, it's easier to test these classes because we can have here injected a dependency that
we don't know if it's an actual service, that it's connecting to the Bakken and fetching data or a
mock test implementation.
So that's one of the benefits of dependency injection.
Another benefit in the context of building you guys with a lot of nested components is that if, for
example, one of our dependencies, such as, for example, the course care that these deeply nested
inside our UI, if that dependency also leads to this service, we can inject it here directly via the
constructor and we don't have to pass it as an input property.
If in order to access our dependencies, we would need to receive them as inputs, that would mean that
we would have to pass the dependency all the way down the componentry.
In this case, they're only a couple of levels, but in a more complex way, you will have several levels
of component nesting, which would mean that these courses service here would have to be passed all
the way down the componentry until it reaches the leaf component, such as, for example, the Corsair
component, as you can imagine, that would very quickly become cumbersome for larger applications.
So this way of injecting dependencies transparently via the constructor is much easier to reason about
and maintain.
Let's now think about how angular obtains these dependency.
So again, the class does not instantiate the courses service.
It gets the courses service injected by ANGULAR.
The question here is how is angular creating these courses service?
Well, we see that we were using here this special provide in syntax that we say that will get back
to later on.
Now is the moment to understand exactly what is going on here.
Let's for a moment remove here this provide in and run our application to see what happens.
So if we lower the application, we can see that now the application is broken.
And if we have a look here at our console, we are going to see the following error message.
No provider for courses service.
So let's understand exactly what this means.
So what this message means is that somewhere in our application, for example here, the application
component we are trying to inject here a dependency called courses service and the dependency injection
system of ANGULAR does not know how to create these dependency.
And it says so with the message no provider for courses service.
So the question here is, what is the provider?
The provider is what creates the dependency on behalf of the angular dependency injection system.
So somehow the dependency injection system needs to create an instance.
Of course, this service, the way to create that dependency is the provider.
The provider will give the angular dependency injection system a function known as a factory function
that creates a dependency.
The angular dependency injection system will then call the factory function, generates the dependency
when it sees that it needs it and passes it on to parts of the application, such as, for example,
the application component via the constructor.
So in order to solve this error, we need to create a dependency injection provider for these class
courses service.
And that is exactly what we were going to do.
We are going to write this provider manually as an exercise to understand how the dependency injection
system works.
This error here and the provider for this service also means that before when we were using this special
syntax provided in route, we were implicitly behind the scenes and without knowing we were creating
the provider, we are going to revisit this syntax later on.
This syntax allows us to create what is known as a three shakal provider.
But before understanding the syntax, we need to understand exactly what the provider is by writing
it ourselves.
Let's now fix the error by manually creating our own provider.
This is coming right up in the next lesson.