- 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.Introduction6 lessons, 42:00
1.1Introduction00:48
1.2Get Started With Angular-CLI11:09
1.3Developing With Angular-CLI13:17
1.4TypeScript vs. JavaScript06:54
1.5Angular Modules From the CLI04:31
1.6CLI Options05:21
2.Get Started With Angular7 lessons, 42:38
2.1Bootstrapping the Application04:30
2.2The Application Module04:15
2.3The Application Component08:06
2.4Component Styling03:06
2.5Global Styling05:11
2.6Creating a Component With the CLI09:34
2.7Creating a Service With the CLI07:56
3.Core Concepts7 lessons, 55:20
3.1Component Trees06:20
3.2Dependency Injection06:52
3.3Content Projection05:38
3.4Component and Directive Lifecycle Methods06:31
3.5Component-Only Lifecycle Methods05:28
3.6Decorators07:36
3.7Models16:55
4.Template Deep Dive11 lessons, 1:10:56
4.1Basic Data Binding With Interpolation05:35
4.2Property Bindings07:07
4.3Attribute Bindings03:29
4.4Event Bindings08:16
4.5Class and Style Bindings05:44
4.6The `NgClass` and `NgStyle` Directives05:04
4.7The `*ngIf` Directive04:41
4.8The `*ngFor` Directive09:29
4.9Inputs05:33
4.10Using Pipes in a Template07:31
4.11Using Pipes in a Class08:27
5.Forms10 lessons, 1:45:41
5.1Handling User Input With Template Reference Variables07:06
5.2Template-Driven Forms11:10
5.3Template-Driven Forms: Validation and Submission14:00
5.4Reactive Forms11:26
5.5Using a `FormBuilder`08:01
5.6Reactive Validation With Built-in Validators14:53
5.7Creating Custom Validators for Template-Driven Forms12:18
5.8Creating Custom Validators for Reactive Forms08:26
5.9Observing Form State Changes12:40
5.10Working With the `@HostListener` Decorator05:41
6.Routing9 lessons, 1:15:10
6.1Defining and Configuring Routes07:53
6.2Rendering Components With Router Outlets10:14
6.3Using Router Links for Navigation05:25
6.4Navigating Routes Using the Router06:24
6.5Determining the Active Route Using an Activated Route07:16
6.6Working With Route Parameters10:42
6.7Using Route Guards07:36
6.8Observing Router Events10:55
6.9Adding Child Routes08:45
7.Using the HTTP Client5 lessons, 56:24
7.1Sending an HTTP Request10:52
7.2Handling an HTTP Response11:22
7.3Setting Request Headers12:33
7.4Intercepting Requests09:04
7.5Finishing the Example Application12:33
8.Testing10 lessons, 1:23:27
8.1Service Unit Test Preparation10:45
8.2Unit Testing Services13:24
8.3Component Unit Test Preparation12:35
8.4Unit Testing Components07:27
8.5Unit Testing Component Templates06:58
8.6Unit Testing Pipes04:41
8.7Unit Testing Directives04:56
8.8Unit Testing Validators04:48
8.9Unit Testing Observables11:37
8.10Unit Testing HTTP Interceptors06:16
9.Building for Production1 lesson, 03:40
9.1Building for Production03:40
10.Conclusion1 lesson, 01:32
10.1Conclusion01: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.