Hello, everyone, and welcome back in this lesson, we're going to talk about three Shakal providers.
So far we have been using here to the providers property of the component decorator to generate our
coarsest service.
Let's talk about an alternative syntax for adding a service to our angular dependency injection system
that does not involve the provider's property.
These new Syntex is known as an angular clickable provider.
And in order to understand the advantage when compared with these providers that we are declaring here,
let's notice the following.
We are defining the provider for this service here at the level of the application component.
Now, in this particular application, we have injected here the service and we have used it.
But there could be potentially situations where we define a service, for example, in a third party
module, and that service might not get injected at all in our application.
Imagine a generic component or a generic module that has a lot of services attached to it whenever we
provide the service here at the level of the application component.
We are always going to end up having the code for the unused service in the application bundle.
So the application bundle will be larger because it contains several unused services that just happen
to be provided by a third party component or module.
But we have never used it in our application.
So we want to avoid having to add that code to our application bundle is just going to make the application
bundle larger without any need.
Notice that if the service does not get injected anywhere on the application, then the angular dependency
injection system is not going to instantiate the service.
So that's not the problem.
What we are trying to avoid is the inclusion of unused code in the bundle.
The angular dependency injection system works in a lazy way, and if a service is not requested by any
dependency, the provider will never get called and the service will never get creative.
But with the syntax in the courses, service would still be added to our bundle, even if it would not
be used.
In order to solve this problem, we are going to remove the use of this provider's properties syntax
and instead we are going to define here the configuration for our dependency injection system here at
the level of the service itself.
So if you remember before we were using here and options property bust in here to the injectable decorated
and we were specifying here one of these properties provided in notice that we also have available here
several other properties that are very similar to what we saw before.
These are the properties that are needed for configuring a provider for the courses service class.
We can specify here a factory function.
We can specify here a class.
We can even specify here a default value.
These are the same properties that we were using here in our application component when defining a provider
using the provider's property.
So one of the properties that we can specify here, for example, is the use factory function.
We can specify here a factory function that is going to instantiate a coarsest service.
As we have seen, the factory function looks something like this.
We can create here a function that takes a parameter, which is the HTP client and passes it on here
to the courses service.
Notice that we are getting here and er and this is because this configuration object has amendatory
property called provided in, so provided in is going to help us determine where should this service
be instantiated.
As we have seen before, the angular dependency injection system is hierarchical so we can instantiate
a service such as the courses service in multiple levels of the application.
So here we are going to say that we want to inject this service in the very root of the application.
So this service will be an application wide singleton that is available to the whole application.
Notice that these factory function also needs dependencies.
So just like before we can specify here and the array of dependencies and in this case, the courses
service only needs here the ECB client.
So we are declaring it here in the Depp's property and we d we have done something very similar to what
we did before.
We have manually written here a provider function for our courses, service dependency.
Let's try this out.
If we reload here, the application, we are going to see that everything is still working as expected.
But this time around, our application component will only need the courses service if it gets it injected
here in the constructor.
If we would go to the whole application and we would remove all occurrences of the.
Of the his service, then in the end, our application bundle will not include the code for this unused
service.
So that's the big advantage of using these three shaquill provider, Syntex, that we are using here
inside the injectable decorated note is that just like before, we don't need to write here our factory
provider function manually.
We can instead use here the use clasp property just like we were doing before, and we can define here.
The course is service Gless.
So if we relo the application, everything is still working as expected.
And as you can imagine, this property here use class just like before can even be admitted.
And if we leave only here, the mandatory property provided in our application is still working correctly.
The question here is when should we use the traditional syntax when compared here to the syntax using
the provider's property?
Well, if our service does not have any state and it's an application wide singleton, such as, for
example, the this service, then we should always use the three provider syntax that we see here.
We should only use the provider syntax if our service has some state that is specific to the component
that we only want to have visible at the level of the component for singletons in general, we should
always prefer the three syntax because it results in smaller application bundles and better runtime
performance.
Let's now continue our deep dive into the angular dependency injection system.
We are going to talk about how to inject objects instead of instances of classes.
This is going to be very useful if you want to inject some global configuration in our application.
Also, we are going to cover a series of dependency injection related angular decorator's.