FREELessons: 67Length: 8.9 hours

Next lesson playing in 5 seconds

Cancel
  • Overview
  • Transcript

2.7 Creating a Service With the CLI

As well as creating components, we can also use the CLI to create services. Just like in the original AngularJS, services are commonly used to share application logic and business rules between different components. In this lesson you'll learn how to create one.

1.Introduction
6 lessons, 42:00

1.1
Introduction
00:48

1.2
Get Started With Angular-CLI
11:09

1.3
Developing With Angular-CLI
13:17

1.4
TypeScript vs. JavaScript
06:54

1.5
Angular Modules From the CLI
04:31

1.6
CLI Options
05:21

2.Get Started With Angular
7 lessons, 42:38

2.1
Bootstrapping the Application
04:30

2.2
The Application Module
04:15

2.3
The Application Component
08:06

2.4
Component Styling
03:06

2.5
Global Styling
05:11

2.6
Creating a Component With the CLI
09:34

2.7
Creating a Service With the CLI
07:56

3.Core Concepts
7 lessons, 55:20

3.1
Component Trees
06:20

3.2
Dependency Injection
06:52

3.3
Content Projection
05:38

3.4
Component and Directive Lifecycle Methods
06:31

3.5
Component-Only Lifecycle Methods
05:28

3.6
Decorators
07:36

3.7
Models
16:55

4.Template Deep Dive
11 lessons, 1:10:56

4.1
Basic Data Binding With Interpolation
05:35

4.2
Property Bindings
07:07

4.3
Attribute Bindings
03:29

4.4
Event Bindings
08:16

4.5
Class and Style Bindings
05:44

4.6
The `NgClass` and `NgStyle` Directives
05:04

4.7
The `*ngIf` Directive
04:41

4.8
The `*ngFor` Directive
09:29

4.9
Inputs
05:33

4.10
Using Pipes in a Template
07:31

4.11
Using Pipes in a Class
08:27

5.Forms
10 lessons, 1:45:41

5.1
Handling User Input With Template Reference Variables
07:06

5.2
Template-Driven Forms
11:10

5.3
Template-Driven Forms: Validation and Submission
14:00

5.4
Reactive Forms
11:26

5.5
Using a `FormBuilder`
08:01

5.6
Reactive Validation With Built-in Validators
14:53

5.7
Creating Custom Validators for Template-Driven Forms
12:18

5.8
Creating Custom Validators for Reactive Forms
08:26

5.9
Observing Form State Changes
12:40

5.10
Working With the `@HostListener` Decorator
05:41

6.Routing
9 lessons, 1:15:10

6.1
Defining and Configuring Routes
07:53

6.2
Rendering Components With Router Outlets
10:14

6.3
Using Router Links for Navigation
05:25

6.4
Navigating Routes Using the Router
06:24

6.5
Determining the Active Route Using an Activated Route
07:16

6.6
Working With Route Parameters
10:42

6.7
Using Route Guards
07:36

6.8
Observing Router Events
10:55

6.9
Adding Child Routes
08:45

7.Using the HTTP Client
5 lessons, 56:24

7.1
Sending an HTTP Request
10:52

7.2
Handling an HTTP Response
11:22

7.3
Setting Request Headers
12:33

7.4
Intercepting Requests
09:04

7.5
Finishing the Example Application
12:33

8.Testing
10 lessons, 1:23:27

8.1
Service Unit Test Preparation
10:45

8.2
Unit Testing Services
13:24

8.3
Component Unit Test Preparation
12:35

8.4
Unit Testing Components
07:27

8.5
Unit Testing Component Templates
06:58

8.6
Unit Testing Pipes
04:41

8.7
Unit Testing Directives
04:56

8.8
Unit Testing Validators
04:48

8.9
Unit Testing Observables
11:37

8.10
Unit Testing HTTP Interceptors
06:16

9.Building for Production
1 lesson, 03:40

9.1
Building for Production
03:40

10.Conclusion
1 lesson, 01:32

10.1
Conclusion
01:32


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.

Back to the top