Transcript from the "Services" Lesson
[00:00:00]
>> We've talked about directives, let's talk about services. And a service is generally more often than not just a class. And this applies to more than just Angular. You should do one specific thing, and so you want to have single purpose fine grained services. As well, and I feel like this deserves its own slide but I'm going to just say it here, is that your component should do two things and only two things.
[00:00:41] One, consume just enough data to render its templates, capture user events, and then delegate that elsewhere. The reason why I bring that up here is because your business logic needs to happen outside of the component, which happens inside of a service. So your services end up you have very very razor thin components in these kind of rich domain models.
[00:01:10] That are built out via services elsewhere in the application. So the burden of business logic is alleviated off of the component shoulders input into services. It is considered best practice to always use injectable with a service so that the metadata is generated correctly. If you generate a service from the CLI, this is what you're going to get.
[00:01:37] I can't think of any reason not to do it. So just do it. Also by using the provideIn root property, which, if you generate a service from the CLI, it's going to have this in here. What you're doing is you're specifying that Angular should provide or make that service available to the root injector.
[00:02:02] So, there is this concept of being able to make a service only available to a specific kind of subtree or slice of an application. Again, this would be the exception, not the rule. And so to make things easier that before you would have to essentially explicitly define your services in kind of every single module or even to the point of one point, even if a component used to service you had to inject it in.
[00:02:32] But by using provideIn root that makes it available to the root injector which makes it a lot easier to wire it up into your main application. So what we have here injectable you can see here providedeIn root, so we're just calling the injectable Decorator, and we're saying make this available to the root injector.
[00:02:57] And under the hood, it looks very much like a component and that we have properties methods in the constructor. In this case we're injecting HTTP client. Which I think it's probably not too hard to figure out that this is responsible for communicating with a courses API and fetching all of the courses.
[00:03:24] But the main thing here is injectable metadata provided in root. So now it's available for everything. Because it's in the root injector. The question is, if you provided in root, where else can you provide a service if I'm not mistaken? I think that's the question like what are the other cases?
[00:03:45] And so you actually answered your question in that you can provide it into the root injector. So it's available for everything or you can provide it and make it available specifically for like some kind of a sub module. And so where that gets interesting is, let's say you have a users service.
[00:04:15] But you have two branches of the application that depending on, let's say, your access level, that the business rules that govern how you're able to interact with the application are totally different. And so this is one of the beautiful things about dependency injection, is that you might have like an employee user service to where if you're on this tree of the application you get a specific user service that has business logic for a say employees.
[00:04:45] Then let's say you have like a contractor You know, business logic that's totally different. And so what you would do then is you would converge on like a naming convention of user service, but then under the hood, depending on where somebody is, you would just swap out that service.
[00:05:11] And then somebody would just get that specific functionality. So, imagine you program, let's say five services to an interface. And then depending on where you are, you can inject the appropriate service for that particular module. Or even at a component level, you can override a service being injected.
[00:05:36] So actually, the injector is every component even has access to the injector and you can override that essentially at runtime, which by the way, when we get into testing we do quite frequently. So, that is the use case, is that you want to provide one version of the service to maybe one part of the application or all the application.
[00:06:02] But let's say in a sub part of it that you want to actually override it and you want to keep the interface and all the naming convention the same you just want to use a different version of that