2.7 Creating a Service With the CLI

Hi folks, in this lesson, we're gonna see how we can use the Angular CLI to scaffold out a new service. If components are the most common Angular feature, services are the next most common. Just like in Angular JS, in modern Angular services are used to share common functionality between components. We only have a couple of components in the application so far, but we will be adding some more shortly. And we are going to want to share functionality between them. So let's create a service ready to do that. At this stage, we can create a very simple service to store some constants in. Just like with components, we can use the CLI to quickly and easily generate a new service for us using a very similar command that we used to generate the component in the last lesson. This command is very similar to the one we used before, we are running the ng generate command. This time we want to generate a service and that service is gonna be called constants. So when this command has finished, we can see that it has created the service and the service.spec file for us. It hasn't updated the app module, because we might not want this to be a global service that can be injected into any component. We can restrict services so that they only are available within a particular component, but in this case, we are going to use it throughout the app. So, let's take a look at the service that has been generated. And we can see that it has just been created in the root of the app folder, and this is much simpler than the component. We import something called Injectable from Angular. This is another type of decorator, but this is a much simpler decorator. We don't have to pass in a configuration object. We can just annotate a class to specify that we want it to be injectable. And this constant service will be injectable. We'll be injecting it into other components and we also have an empty constructor. Now services don't have life cycle methods. So the on init interface hasn't been imported, and the class hasn't given an ng on init method. You can't do this with services, that's why the CLI hasn't done it for us. So we don't actually want this service to be generated in the root of the application. So we're going to delete it and create it again. The problem is that we'll generally add a number of services, it's not a huge problem at the moment because we only had one of them. But when we have lots of services and their associated specs files, the root of the folder will quickly become very cluttered. The architecture of components is fantastic. Each component is a feature of the application, and everything to do with that feature goes into the component folder. The folder becomes a feature folder. And this is great for all sorts of reasons, including things like planning out work and making estimates, and just keeping the application code nicely organized. The architecture for services is not always so clear. Because they're so often shared between components, there is often no single feature to which they belong. So we can put them in a more general centralized location. What I've seen done before is to have them in a folder in the root of the app folder called _services, and all of these shared services can go in here. Giving the folder name an underscore at the start means that the folder will go to the top of the app folder. And so, it will always be easy to find even if we got lots of other feature folders. Services don't always have to be shared across the whole application. On really big features you might break them down into a number of sub features and have a service that is only available for use with these sub features. So in that case, the service might go into the parent feature folder, but that's not the case here. We don't have anything that's gonna be that big to warrant numerous sub components. So, let's create the service again. We can run almost the same command as before, but with a slight modification. So, this time instead of specifying just the name of the service we want to create, we specify a path instead. So we'll see almost the same output as before. Let's just refresh the editor in the background here. And it has created the folder for us, but it hasn't given it an underscore, it's given it a hyphen. So this seems to be a problem with the CLI. It might get fixed at some point, it might not. Let's just fix that ourselves manually now. And we can see that our service is now in this generic _services folder. And when we want to add new services, when we specify the path _services, the CLI will be able to find this folder, and it will put them in the correct place. So that's fine. So let's go ahead and add some constants now. And we can do this in the constructor(). So you'll notice that we get some lint errors here. Let's just hover over one of them. And it says that the property COLORS does not exist on type ConstantsService. What this means is that we need to add some types to the class to specify the types of properties. We can add the type information above the constructor. So we specify that each of these properties should be public. They could also be marked as private, meaning that they can only be used within the same class, or protected, which means that they can be used in the same class and any class that extends this class. But in the case of this particular service, this wouldn't be very useful. So, the editor's still not entirely happy, and that's because the last property is not actually an array of strings, it's an array of numbers. And now we can see that Visual Studio, at least, is happy with this class declaration. So now this service is ready to be used. So in this lesson, we saw how to create a service using the CLI. We saw that services are simpler than components and do not have associated templates or style sheets. We saw that we can use the Injectable decorator to tell Angular that we intend to inject this service into other services or components. And we also saw how to add type information for properties of a service. Thanks for watching.