This course has been updated! We now recommend you take the Angular 9 Fundamentals course.

Check out a free preview of the full Building Awesomer Apps with Angular course:
The "Review of Angular" Lesson is part of the full, Building Awesomer Apps with Angular course featured in this preview video. Here's what you'd learn in this lesson:

Reviewing first part's topics and taking questions from students, Lukas covers modules, routes, components, and services in Angular.

Get Unlimited Access Now

Transcript from the "Review of Angular" Lesson

[00:00:00]
>> Lukas Ruebbelke: So I'm going to skip the getting started session, because I think everybody is up to speed on that. And so, let's do a review. So let's start out with just have a conversation. So this is the Angular Big Picture. Who can tell what is the purpose of NG module?

[00:00:25] You looked like you had an answer, so let's go with you.
>> Speaker 2: It's encapsulating the whole obligation and it's getting a way to, an entry point for you into the app.
>> Lukas Ruebbelke: Keep going, you're on the right track.
>> Speaker 2: You have an app, you have a base module to it and you could have some modules.

[00:00:46] And each module may be something like for a big banking app. Say, for example, we're one module and saving functions in other modules. You could have multiple modules in an app. I know we could have components and services in it, and these all modules can be all boosted up using once in a module.

[00:01:03]
>> Lukas Ruebbelke: Right, so that is correct. So the idea is that you have module that can have other modules and other things. Specifically.
>> Speaker 3: Kind of like a house for all your dependencies.
>> Lukas Ruebbelke: Also good, yes. So it's a way to essentially, so it has dependencies components modules. What other modules, etc., is it's really this container, more so kind of a manifest, it tells Angular how to wire itself up.

[00:01:36] And so, you're communicating to Angular itself, saying, I want to build this application and this is what I want in it. I want these components, I want these sub-modules, I'm going to use these services. And I want to bootstrap, if it's the top level module, using this component.

[00:01:54] And so, I think of it really as just kind of a blueprint of Angular this is how I want you to put yourself together. Now, that is at the framework level. What is the purpose of just an ES6 module?
>> Speaker 2: You can, you can export the ES6 more of your but it's a construct of defining an entity, NES6?

[00:02:21]
>> Lukas Ruebbelke: Yeah, so that's good, same thing. It's a container, but it's an organizational mechanism at the language level. So it allows you to organize your application into these kind of blocks. That then using for instance like Web PEC, you can go through and say okay, I need to put these things back together, and they know how to do that.

[00:02:44] So unlike ES6, where you just kind of had to put everything originally kind of pre-gulp and grunt is because you know, I think we've all seen this where you have an index file of like 20. Your script tag's in there. You're basically, inserting all these scripts and if you get it in the wrong order, I've been there when I've been like I don't understand why this isn't working.

[00:03:05] And then you have to start swapping things up the chain and just the order till you get it just right. So modules kind of solve that problem, cuz it allows us to define just what we need and it puts it together in a way that's going to work.

[00:03:18] So, ES6 Modules are organizational mechanisms at the language level. So this allows us to organize our code and actually put it back together. NgModules is an organizational mechanism at the framework level. So what about routes? You have already answered like 17 questions. So you're on pause until I get it from, you know what I'm gonna just go random, so what are routes for?

[00:03:48]
>> Speaker 4: Routes are a ways to switch to different views or pages and just lets you control that switch.
>> Lukas Ruebbelke: Yeah, so it's a way to switch to views or pages. I think specifically it's a way to define a specific state in your application, which is oftentimes by pages which you would consider.

[00:04:09] So a lot of times I would do my routes on a per feature basis, which we've seen here. We have an items route which is route. Home and so it just allows you to say, I want to match this URL to this state in the application. Okay, so this is like a softball question right here.

[00:04:31] What role does components play? For my silent friend in the striped shirt
>> Speaker 5: Components
>> Speaker 5: Is like a section. Section is up your views and stuff like that how to describe. The properties and behaviors of that certain component and also, I guess you can also with components you can also localize your, specify your, I guess style stuff like that for easier batchment so.

[00:05:24]
>> Speaker 5: And it's a little more easier to, I guess, maintain,
>> Speaker 5: Your, I guess, structure up here over Hawk-
>> Lukas Ruebbelke: Yeah.
>> Speaker 5: Application, so-
>> Lukas Ruebbelke: That's it, so I think in so many words they're trying to say like they're Legos for application. It's a, and so that's it.

[00:05:48] I think of components as kind of the fundamental building block for the application. And so, what it allows you to do is self-contain, self-incapsulated units that has your template, your styles, and your functionality. And you can pick it up and move it somewhere else, so ideally, if you do it right, your components are portable.

[00:06:07] Just as some of you pick up a Lego, put it over here, put it over here, put it on the stairs, so I step on it in the middle of the night as my six year old is so fond of doing. But the point is that we encapsulate a bit of functionality, so that we can use it wherever we want.

[00:06:23] So just random new components, they're building blocks.
>> Lukas Ruebbelke: What about services?
>> Lukas Ruebbelke: Yes?
>> Speaker 6: Kind of, the business logic.
>> Lukas Ruebbelke: Yeah.
>> Speaker 6: Where you can call APIs and stuff.
>> Lukas Ruebbelke: Mm-hm, yeah, so that's exactly it. Is any kind of business logic, domain models, like shared logic, they go in the services and you want your services as rich as possible and to that end, a component should do one of two things.

[00:07:00] One, is consume just enough data to satisfy the template and capture user events, and then route that event to the appropriate service. And so, what you want, is you want your components to be very, very thin and specific. I say this because in Angular JS, and I did Fletch for many years, you would have this problem of having this component, that tons of business logic and it just did way too much.

[00:07:28] Well, now, it's like I need to test this, I need to move it somewhere else, because it's so tightly coupled that it's really hard to work with. So I have a really small components, really rich models solves that problem very nicely. All right, so what kind of mechanism is in play here?

[00:07:47] We've already talked about it just a little bit, but what is this line right here? What are we doing?
>> Speaker 7: Making the component available to the rest of the app.
>> Lukas Ruebbelke: Yep, so essentially, it's ES6 modules again. We're importing stuff, so we can use it. And we're exporting it, so that it is available to the rest of the app.

[00:08:14] So let's talk about these properties on NgModule. Declarations are for what?
>> Speaker 8: Components that we build.
>> Lukas Ruebbelke: Yep, and so generally it's components. But anything that goes into the view pretty much will go into a declaration. So this one's a softball, what goes here in imports?
>> Speaker 9: [INAUDIBLE]

[00:08:41]
>> Lukas Ruebbelke: Uh-huh, all right, and providers?
>> Speaker 8: Services.
>> Lukas Ruebbelke: Yeah, and bootstrap? Somebody who hasn't answered yet.
>> Speaker 10: The entry point into the app.
>> Lukas Ruebbelke: Good, very good. And so I think we just kinda covered this. This is self-explanatory. The entry point is at module, which then, according to the previous example, is going to bootstrap app component.

[00:09:11] So what is the basic structure of a route? A route consists of kind of two things. What are those two kind of elements in the recipe? Yes?
>> Speaker 11: Path.
>> Lukas Ruebbelke: Path.
>> Speaker 11: Component.
>> Lukas Ruebbelke: Yes, ding-ding, so it's essentially taking a path, a URL path and matching it to a component, which then gets loaded into a router outlet.

[00:09:38] Now, I don't think we talked about this yesterday. But I would wager if somebody put their thinking cap on, we could figure out what this double asterisk does.
>> Speaker 7: It's a wild card?
>> Lukas Ruebbelke: Wild card.
>> Speaker 7: So-
>> Speaker 12: It's like, any pages that may not exist?
>> Lukas Ruebbelke: Yes, so if I went to, for instance, the app, and I typed in I wanted to go to Mark is a beast page.

[00:10:19]
>> Lukas Ruebbelke: You have the wild card in there saying, hey, we don't know what to match this to. Just basically reroute it or load this component. So you could do, for instance, if you had a 404 component, you wanted to just say not found, like you're trying to do something abort or revoking your IP address and the authorities will be notified.

[00:10:39] And you can have a specific component you wanna load or you can just reroute it back to your GUI, which I recommend everybody have, they implement this. So, all right, what are two main pieces of a component?
>> Speaker 13: Class and a template.
>> Lukas Ruebbelke: Class and a template, boom.

[00:11:01] And how do they communicate? How does Angular know about this thing? How do we kinda bind these things together?
>> Speaker 13: [INAUDIBLE] databinding.
>> Speaker 2: Metadata.
>> Lukas Ruebbelke: Metadata, yes, good. So what does implements OnInit mean?
>> Speaker 2: Implementing the interface.
>> Lukas Ruebbelke: Yep, and so when we implement an interface, we are essentially required to satisfy that contract of the interface.

[00:11:34] So this is a fun one. So how does NG on an network, what is the point of this?
>> Speaker 14: The initial state.
>> Lukas Ruebbelke: Kind of. So I'll give you a hint. It's an event, it's something that happens. And so you had the first part right. Convert that into a moment in time.

[00:11:58]
>> Speaker 2: The lifecycle hook starts after the constructor is done.
>> Lukas Ruebbelke: So not the constructor.
>> Speaker 2: Starts after the constructor is done.
>> Speaker 15: It starts after there's an action that takes place, and if it's-
>> Lukas Ruebbelke: Yes, which is? Say what you just said.
>> Speaker 15: Initials. Initial state.
>> Lukas Ruebbelke: Yes, so essentially, it's a lifecycle, so it's an event in time.

[00:12:18] It does happen after the constructor, but it fires when your initial state is ready. And how do we know that is because ngOnInit changes has fired at least once. So basically, all the bindings have been triggered at least once. And so this is where any kind of binding depending logic that you want to initialize with should go in here and not the constructor.

[00:12:45]
>> Lukas Ruebbelke: So how do we inject a dependency into our component?
>> Lukas Ruebbelke: I think you know the answer.
>> Speaker 16: With a constructor.
>> Lukas Ruebbelke: Yes, boom, nailed it! So what about private? Why do we use the private keyword here? I think you know this answer too.
>> Speaker 16: That is a little confusing, but it's to do with making a field in the class.

[00:13:16]
>> Lukas Ruebbelke: Mm-hm.
>> Speaker 16: So the ItemsService.
>> Lukas Ruebbelke: That's exactly it.
>> Speaker 16: Okay.
>> Lukas Ruebbelke: So essentially, I call it constructor assignment. But what it's doing is, under the hood, it's saying, we're going to need this itemsService, in this case, somewhere else in the application. Let's go ahead and assign it to a local property.

[00:13:37] So this is, if I did not have private on there, I would not be able to reference itemsService cuz it would just be a parameter in the constructor. And so I think a good way, and I showed this yesterday, but kind of an easy way to see this is and this is just kind of a side note.

[00:13:56] But if you're ever doing something in TypeScript, what is happening here? What does this actually look like under the hood? I highly recommend just jump in the playground, and check it out. So let me just kinda back this up. They must be using local storage to keep track of my stuff.

[00:14:19]
>> Lukas Ruebbelke: So I'm gonna dial this in. Let's go,
>> Lukas Ruebbelke: Here.
>> Lukas Ruebbelke: And so you can see now, it's saying, hey, we don't know what this is because this is just a parameter to the function. And that's basically what it's scoped to. It cannot live outside of the function.

[00:14:45] But now look at the constructor or this is the ES5 equivalent when we go and we add this modifier. And under the hood, it's just saying take this parameter and assign it to a local property of the same name. So now we can use this outsider. So this is, in a nutshell, what is happening.

[00:15:09] But it is helpful to sometimes jump into TypeScript and see what it's actually being compiled down to. All right, by the way, excellent answers. Your silence, I'm not fooled anymore. You know way more than you're letting on. So air five, [SOUND] this is metadata.
>> Lukas Ruebbelke: There is an exception to this, so I'm not gonna get too pinned down on this.

[00:15:38] I think they loosened up a bit. But for the most part, what are two things that a component must have?
>> Speaker 17: A selector and a template.
>> Lukas Ruebbelke: Yes, a selector and a template. I believe that you can now have a component without a selector if you only ever loaded a route.

[00:16:01] But for the most part, well, I think, one, if you did a component without a selector, then you are severely limiting your options. That for the most part, every component must have a selector and a template. So right now, we have an external component template. What is another way that we could do this?

[00:16:26]
>> Speaker 17: Instead of saying template URL, you could just say template and put the template right there.
>> Lukas Ruebbelke: Right.
>> Speaker 17: Put the HTML right there.
>> Lukas Ruebbelke: Yep, so you can do it inline. Now, what would be a reason why you may want to do this instead of using it as an external template?

[00:16:48]
>> Speaker 18: You have a check on making sure your component doesn't get too big and tries to do too much.
>> Lukas Ruebbelke: Yep, so I think there's pros and cons of each. And I think there's people who feel strongly about either way.
>> Lukas Ruebbelke: For me, I think if you are a developer, in other words, like you're a JavaScript developer and you happen to just be doing templates.

[00:17:10] Like I'm writing JavaScript but what I'm writing has this template that I just have to do. So it's very common for somebody to do them both. Then I think doing inline templates is okay. In fact, I know a bunch of React developers that would prefer that. Because they're JavaScript developers who just write basically templates for their components.

[00:17:30] On the other hand, I've been in an organizations where you have a dedicated UX, UI person, they just do everything pixel perfect, and they do all the layouts, and then they hand them off to the developers and we then work them into the application. To that end, doing them inline would be very, I think it would be a really inefficient workflow.

[00:17:54] Because what you would have to do is then basically hoist all of the additional knowledge of how do you run app, how do you do these things and force them into your development environment, when really, they're just doing layout. So when you have somebody who's doing specifically layout, I think it makes sense to just to have them do external templates that you can just pull in and wire up.

[00:18:17] So it could go either way. I think if you're primarily a JavaScript developer who's doing templates, this way may be okay. But if you have a dedicated team that does the layouts and different things, I think doing external templates is going to work better in that case, from a workflow standpoint.

[00:18:35] All right, let's talk about binding. What is the easiest way to bind a simple text value into a template? And this is pretty much in every templating language for the most part. Off the top of my head, I think that everything that I know of uses this kind of binding?

[00:18:57]
>> [CROSSTALK]
>> Lukas Ruebbelke: So now, if you wanna send data to the template, say what you just said, brackets, yes. So this is property binding. By the way, for some odd reason, yesterday these graphics did not have arrows in them, and it kinda bothered me, but the show must go on.

[00:19:21] I got to the hotel, fired up Keynote, and they were there again. It was some weird random bug, it's just like, we're not showing you these arrows today. And then I looked at the PDF I generated, they're not in there. But they were in the Keynote.
>> Lukas Ruebbelke: I just gave the answer.

[00:19:37] So vice versa, event handler. Now, if we wanna do two-way data binding?
>> Speaker 19: [INAUDIBLE]
>> Lukas Ruebbelke: Banana in a box. Angular hug. All right, this is a really, really important graphic. Notice the arrows are back? Yay, so
>> Lukas Ruebbelke: What binding would we use on this side of the template over here?

[00:20:06] So class to template.
>> Lukas Ruebbelke: Square, property binding. Now, from the template back to the class?
>> Speaker 19: [INAUDIBLE]
>> Lukas Ruebbelke: Event. Okay, so it may seem I'm kind of a broken record here talking about if it's one way, it's this. If it's this way, it's this. So property and event binding.

[00:20:30] But when we get into component driven architecture, it'll make a lot more sense why I keep talking about kind of this circle, this unidirectional circle of data goes in via properties, events come out via event bindings. So properties and events. All right, so this is what over here?

[00:20:53]
>> Lukas Ruebbelke: There we go.
>> Lukas Ruebbelke: We just call this, I don't know, string binding, curly brace binding, easily the least sophisticated. So this over here is
>> Lukas Ruebbelke: What?
>> Speaker 19: Property binding.
>> Lukas Ruebbelke: Property binding. And what are we sending into this element?
>> Lukas Ruebbelke: Experiment which we're getting off of this NG4 over here.

[00:21:30] So we're doing this, we're looping over this experiment component, and saying that for each experiment in this array, go ahead and instantiate this component and pass this experiment object into it. So I'm already starting to hint at what we're gonna get into with architecture. Because last I checked, the experiment wasn't a known standards based HML attribute.

[00:21:56] So something to kind of start thinking ahead. I see you are getting [CROSSTALK]
>> Speaker 20: Yeah, no, I am just having a little trouble. The difference between the double curly brackets and the square brackets, the property vending. Here, you're binding an object which could have various like-
>> Lukas Ruebbelke: Anything.

[00:22:21]
>> Speaker 20: Experiment dot name, dot ID, dot whatever. So you're binding that entire object. Whereas with the curly brackets, you're just saying
>> Speaker 20: That one particular name value of that.
>> Lukas Ruebbelke: Yeah, so curly braces will always result in whatever you pass in being rendered as a string.
>> Lukas Ruebbelke: And so, this is appropriate for certain things, like if I just had this object and I just wanted to do a simple layout.

[00:22:55] So in the case of
>> Lukas Ruebbelke: If we hop in here, let's go to, I think the item list is a pretty easy one.
>> Lukas Ruebbelke: We want to render the name, we want to render the description.
>> Lukas Ruebbelke: Just simple strings on the page.
>> Lukas Ruebbelke: This is where this would go.

[00:23:17] But in other cases, we want to actually send in an object or communicate something to another element, as well as, this will be rendered as a string. Where other times, we want to actually bind to a property on the element itself, or an attribute, or whatever. And so, that's where you would use property bindings.

[00:23:44] So just really, curly braces is just strings that you're rendering on a pace. So it's a very limited albeit useful binding that you will use. Does that make sense?
>> Speaker 20: But with property binding, are you in essence passing the whole object? [INAUDIBLE]
>> Speaker 20: Okay.
>> Lukas Ruebbelke: Yep. So, man, like I am so tempted to just like, get to the punchline but that is exactly it.

[00:24:14] Your passing an object from one element to another, the entire object. Which is really handy, if we have one Lego, what do we do if we have two? We start stacking things up and need to pass it down to a child object.
>> Lukas Ruebbelke: And so, you'll start to see this come into play in just a little bit, hopefully before lunch.

[00:24:43]
>> Lukas Ruebbelke: What is this?
>> Lukas Ruebbelke: A vent, okay? And, what are we doing here? So I know it's two-way data binding, but what's actually happening?
>> Speaker 21: Just create an input field.
>> Lukas Ruebbelke: Mm-hm, and then binding to the message property. And so when you type in the text box, if we were binding to message somewhere else, then it would automatically update.

[00:25:13] So it's just the two way data binding, of its rendering the value in the field, but, as you change it, it's communicating it back to the component class. So how do components and directives differ? This is kind of a softball one, too. Components have, this is just a variation of the one you answered.

[00:25:38]
>> Lukas Ruebbelke: What's that?
>> Speaker 22: Template.
>> Lukas Ruebbelke: Yes, that's it, components have templates. Directives modify an existing element essentially. So, NgFor, NgIf, they don't actually look like anything, they're just applying behavior to an existing element, awesome.
>> Lukas Ruebbelke: No template. So how is the service like a component, but how do they differ?

[00:26:07] Cuz their shape is actually very similar.
>> Speaker 2: Meta data
>> Lukas Ruebbelke: So we have meta data, what else do we have?
>> Lukas Ruebbelke: So they've constructors, they have, I mean they're basically ES6 classes, and so properties, methods are there, constructors.
>> Lukas Ruebbelke: The difference is so,
>> Lukas Ruebbelke: Obviously what goes into the metadata, so a service will never have a template.

[00:26:43] Is that more often than not the only meta data that you will have to just make it available to Angular is ejectable. So it's literally just a class. And so obviously, life cycle hooks, I think I accidentally put a life cycle hook on a service one time. Not happening, but for the most part they're just classes.

[00:27:08] In terms of how they're different is that, obviously they live in different places in the application or abstractions. But a component is a service with a class, or a component is a class with a template. A service is just a class that does strict business logic functionality of that sort.