Hello, everyone, and welcome back.
In this lesson, we're going to cover a series of dependency injection related angular decorator's.
Let's start with the first one, the optional decorator.
So as we have seen before, if we are requesting here a dependency in our application, but somehow
the dependency is not available, we will get an A. Let's reproduce the air.
We are going to switch here to our curtsies service.
And we are going to remove from here the definition of our three shaquill provider.
So what we have here is a class that is not plugged into the dependency injection system that is being
requested here, for example, and also in the course Kerith component.
If we try this out, we are going to see that now the program does not work anymore.
And if we check here the error message, we have the same error message as before.
No provider for course is service.
The reason why this message shows in the console is because whenever Engler sees here a dependency in
the constructor, it assumes that it's amendatory dependency.
So if the dependency is not present, the program should crash in that moment.
There is an alternative to this, which is to market our dependency as being optional by using the angular,
optional decorator.
So if we apply here the optional decorator at the level of the course card component, but also here
at the level of our application component where we are requesting the same dependency this time around,
our program would not crash as early in the bootstrap process.
So we have here a running application with a top menu.
But notice that we now get a different error, cannot remove property load courses of null.
And as we can see, the problem comes here from our application components.
So we are calling here lower the courses in a property that is undefined.
So whenever we mark this dependency as optional, what will happen is that the program will not crash.
But we need to guard in our application against the case when the dependency is not defined.
So this covers the optional decorator.
Let's quickly fix our program before continuing to present a few other dependency injection decorators.
We are going to remove the optional decorator and we are going to put back here to the configuration
of our three Shakiba provider.
Let's not talk about the self decorator.
So if you remember, our dependency injection system is erratic.
If, for example, we remove here the configuration of our clickable provider and we go back to the
previous system where we were creating here multiple copies of our courses service via the provider's
property of the component class, we're going to fall in a situation when sometimes the self the might
be useful.
So in this new setup, our application is still working and we only have one instance existing of the
courses service.
That's the instance that is created here at the level of the application component.
And we don't have here any instances at the level of each course.
As we can see, each course, Carol, is getting injected here.
Our courses service and due to the way that the Iraqi dependency injection system works, these dependency
here is coming not from the component, but from the parent component.
So we have here a same instance of a service that is shared through the component and its child components
via hierarchical dependency injection in certain cases.
This might not be intended.
Sometimes you have a local copy here of a service that you want to be sure that it's private to this
component and that it has not been accidentally injected from somewhere else.
So in that case, we want to override the default behavior of the Iraqi called dependency injection
system, and we want to ensure that this instance really belongs only to this component in order to
ensure that we are going to adhere to a new decorator, which is called the self decorator.
These decorator overrides the default behavior of dependency injection.
These dependency will no longer come from a parent component for sure.
This dependency here, if it exists, it can only come from the component itself.
Let's try these out because this component does not have a private instance.
Of course, this service, we are going to get here again and there.
And if we have a look at the error message we have here, no provider for courses service.
So it's the same message as before, but it's being caused by a different reason.
It's because of the presence of the self-liquidating.
In order to make this program work again, we all have to add here a private instance of the course,
this service injectable.
Otherwise, this will not work.
So if we ever hear this provider configuration, I can see that now our application is working again
now, the same way that we want to override the default injection behavior and make sure that the dependency
is local to the component.
We might want to do the opposite, which is we might want to make sure that there is not a private copy
of this component.
We might want to be sure that this dependency chems for sure from parent components and not from the
current component.
So in order to do that, we will use the Skype self decorated.
These decorator overrides the default behavior of dependency injection in a different way this time
around the course, this service instance will not be searched using our local provider.
So this provider here is ignored and our dependency injection system is going to try to fetch the service
from the parent component.
So if we try this out, we are going to see that our program is still working correctly and noticed
that these courses, service instance here is not coming here from these local providers in order to
prove that the service is not coming from these local provider.
Let's go here to our application component and let's remove these application component provider.
So this provider from the parent component was the provider that was giving the course, this service
instance, to the course care, the child components.
This one here will not work due to the Skype self decorator's.
So if we try this out, we're going to see that we fall again into an error situation.
Let's quickly inspect, hear the message.
So as expected, we have the message no provider for coarsest service, although we have here a local
provider.
We can see that due to the use of Skype self, these local provider is not being taken into account.
So if we remove here the Skype self annotation, we are going to see that the program is still not working.
But now it's for a different reason.
What's happening here is that here at the level of the application component, we are not receiving
here any coarsest service.
The courses service that we have defined here is only visible at the level of the card component and
not at the level of the application component.
So in order to fix this error, we will have to add here another provider which is visible at the level
of this component.
And with this in place, our application is working again as expected.
Let's quickly summarize everything that we have learned in this lesson.
So the optional decorator is meant for situations where we are not sure if a dependency is going to
be provided.
That way, we can mark the dependency as optional and then we have to handle programmatically the cases
where the dependency is undefined.
In our code.
As we have mentioned before, the angular dependency injection system is hierarchical and it has a default
behavior that works correctly in most situations.
There are special use cases where we would like to override the default behavior of the dependency injection
system.
If you want to make sure that we receive dependencies that are created locally at the level of the component,
we should use the self decorator.
If, on the other hand, we want to make sure that we don't receive dependency created locally, but
instead we always get them from parent components, then in that case we should use the Skype self decorator.
These dependency injection decorators should only be rarely needed because in most cases the default
behavior of the dependency injection system is exactly what we need.
Let's now introduce one less dependency injection decorator and then we are going to conclude that the
dependency injection section of this course, after this section, we are going to start a deep dive
on the angular change detection mechanism.
We are going to learn about custom change detection, unpunched change detection and much more.