7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial
FREELessons: 67Length: 8.9 hours

Next lesson playing in 5 seconds

Cancel
  • Overview
  • Transcript

1.3 Developing With Angular-CLI

In this lesson, we'll take a look at some of the build tools that we get with Angular-CLI. This will give us a good idea of how our development workflow is going to shape up.

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


1.3 Developing With Angular-CLI

Hi, folks, in this lesson we're going to look at some of the build tools that Angular CLI provides, and which we'll use during development. We use the CLI to create the app and we're going to use it to build the app or help us build the app at least. So we know from the last lesson that we have all of the required configuration in place. And we know that we have an example module and components in the SRC app folder. To see the example app in action, we can run a command from the command line and have the CLI compile the app and launch a local development server for us to preview it. So Angular will launch the NG Live Development Server, and it will compile the application, ready for us to view it in a browser. And we should see the output at the end here compiled successfully, and then the cursor will just flash. So this command is still running, and it gives us the URL that the web server is listening on, so we can copy that. And we can paste that into our browser. And we get the welcome screen for the demo application which the CLI has created for us. The serve commands will also automatically watch all of our typescript and SCSS files, so let's just go back to the editor, And we can see that there is a styles.scss file in the SRC folder. And let's just add some styling in there. And as soon as we save that file, we can see that there is a new output application has been recompiled because we saved an SCSS file. And if we go back to the browser now, We find that the browser has been refreshed and the new styles have been applied instantly. So the same thing will also happen if we update a TypeScript file as well. So let's go and add a dirty alert in main.ts. And as soon as we save this file, we can go back to the browser, And we see the disgusting alerts. So of course, we're gonna want to remove that again from the TypeScript file immediately, And save that again. And let's also get rid of the hot pink styling because, as attractive as it is, we're not actually gonna use it. And when we go back to the browser, we find that it's back to how it was originally. So the serve command will be running for most of the time while we're developing. If we do wanna stop it, we need to press Ctrl+C in the command line. There are some other useful commands that we'll want to run fairly regularly. We also have the lint command, so the watcher doesn't automatically lint our files for us while ng serve is running. So let's just run the lint command now. So we should see a success message that none of the files have any lint in them, and this command, once it's finished, it just stops. So this one doesn't keep running in the background for us, let's add some lint to one of the files now. Let's go back and make the title of the application super long, because that will trigger a lint warning. The title of the application can be found in the app.component.ts file and it's this title property here, and let's just make that really, really long. So that's like a Klingon page title or something. They're pretty long, that's the point. So to save that, And let's go back around the lint command once again So we see this time that there is a lint error, and the error is in file app.component.ts on line 9. And the warning is that it exceeds the maximum line length of 140 characters. So that specific lint rule is set in the tslint.json file. And we can see it down at the bottom here, max-line-length, the rule is enabled with true and is set to 140. So 140 characters is the maximum line length that we're allowed. This is quite the common setting, which is why it's set by default, and we're gonna leave that as it is. Let me go back to the file in the editor here. You can see that it's got a load of red underlining here. And that generally tells us that there's some kind of problem. So let's just hover the cursor over it, and we can see that Visual Studio has pulled out lint rolls from the tslint.jsn file. And it tells us right here in the editor that the rule has been broken because we've exceeded the maximum line length of 140. So linting is super useful for spotting issues in our code, but it is a bit of a break in our development workflow if we have to keep stopping the development server in order to run linting. So some IDEs, including Visual Studio, which I'm using and also VS code, and I believe there are plugins for other popular IDEs like WebStorm and typically IDEs that are geared up towards JavaScript or TypeScript developments. But some editors, anyway, support this inline linting, so we don't have to actually stop the serve command, and we get the errors straightaway in the IDE and we can just fix them straightaway. So let's fix this one, let's put it back to how it was originally. And we find the red underlining goes away because the linter is happy again. So the NG Lint command does have a couple of extra features that the IDE doesn't have, such as type checking as well as linting. So we will still use the NG Lint command, but for now we're going to look at a different command again, and that is the test command. So let's go back to the command line now. We don't need to stop the process, because the lint process ends, it doesn't just keep running in the background. So now let's run ng test. So this command will also compile the application, but it will compile it using the test configuration. And once it's compiled the app, it will run the unit tests using Karma, and it will pop open this browser window to show us the test output. So we do get an example test file, and that is the app.component.spec.ts file. We can just see it in the background in the editor here. Let's just open that up, we have a couple of very simple tests, so we're testing that the app gets created. We're testing that it has the title app, and that it renders the title in an H1 tag. So pretty generic, but useful just to confirm that all of the test things are set up, and configured, and in place. And we can see that they are and the tests are passing. So this command is a bit like the ng serve command, in that it will continue running in the background. And any time we save a test file, the CLI will recompile the app and rerun the tests for us. So let's just change one of these tests, so we know that the title of the app is set to app. So let's just check that it's set to something else and that should make the test fail. So we've saved the file now, so the test should re-run in the background. And when we go back to the browser we see that they test has failed. And we see why it's failed, because the string app was expected to equal to app1, but we know that the string does equal app. So of course, that's why the test is failed. But let's just go back and fix that. As well as running unit tests, we can also run end to end tests. So let's stop the ng test command. And that will cause the test browser to close. So to run the end to end tests, we just run the command ng e to e. So end to end tests don't stay running in the background, and they're a bit more involved. You can see from some of the output here that uses the selenium test driver. And you probably noticed that a browser opened in the background and then it closed again. So that was selenium automatically running Chrome for us. If we go up to the end to end folder back in the IDE, we can see that there is an example spec file in there, and this has some tests as well. And basically, it just navigates to the Start page and checks that there is a paragraph of text on the page that says Welcome to App. End to end tests are different from unit tests. They test a lot more of the application and they test that the different parts of the application are integrated correctly. And that the application as a whole, or at least bigger features as a whole, work in the way that we expect. And very often, depending on the company that you work at, this might not even be a function of the development team. Quite often this is separated out into a separate QA function. So in this course, we're not actually gonna focus on writing any end to end tests at all. But if you do want to write some, you can look at the example spec and also the PO helper, so that's page object helper. So if you know much about selenium, you know that it uses things like page objects to represent the page. And that gives you all kinds of tools and helper functions to interact with the page. So we can see that the tools here are a method called navigate to, which navigates the browser to a particular route, in this case it's the default route/. And it has another helper called get paragraph text, and that is how the heading is actually selected from the page. So this command isn't long running, it just runs once and then it stops. And like I say, we're not gonna spend any more time looking at end to end tests. The last command that we're gonna look at today is the build command. So we won't normally need to run this command during development. But we can use it to create a production build for the app ready to be deployed. So let's just run that quickly so that you can see the output. So the command is ng build, and we also supply the --prod flag which tells Angular that we want to do a production build. We can also do regular development builds, but that's the same thing that happens when we run NG Serve so generally we won't run NG build unless we're running a production build. So this build takes a little bit longer because Angular has to precompile all the templates and build the application. And it creates these bundle files which have cash-busting URLs, and let's just refresh the Solution Explorer here in the IDE. And we can see that a new dist folder has been created. And this contains the deployable bundle for the application. So once we finish developments, we want to deploy the application. We can run a production build and the CLI gives us this dist folder containing all of the assets that we need to be deployed for the app to function. So in this lesson we looked at the different commands we can run with the angular CLI in order to have different build tasks run. We saw that we can serve the development version of the app, we can lint our code. We can run units and end to end tests, and we can produce a production build, all using the CLI. There is another thing we can use the CLI for and that is creating new things like components or services. And we'll come back and look at this shortly, thanks for watching.

Back to the top