Angular 13 Fundamentals Component Classes & Templates
Transcript from the "Component Classes & Templates" Lesson
>> Components are the atomic building block of Angular applications. And inside of a component, if we're going to talk about this, we need to delineate, there's kind of two kind of separate things that are happening inside of the component conceptually. Is you have your template and you have your class.
[00:00:23] So your component classes are just ES6 classes, and when you define a property on a component class, or a method, that becomes available to your template to bind to or execute. And we can if we need to, this doesn't happen a lot, but you can, well, no, this happens all the time, sorry.
[00:00:52] That when you have a dependency for a component, that is made available by injecting it into the constructor. And so, providers or dependencies, AKA services, these become available via injection into the constructor. And one other thing that is worth mentioning is that you have a component lifecycle that is exposed with hooks.
[00:01:24] And so within a component, you have a number of events that happen within the lifespan of a component. And we have the ability to programmatically capture those and execute some form of logic at these event life cycle or these life cycle events. So a component, you can see here we have an items component, and we have two properties on it, items, selectedItem.
[00:01:55] Now these are available for our template to consume, and we also have a dependency on the item service. So we need to use this to load our item. So we inject this via the constructor and it's available to us. So more on that later, stay tuned. On the flip side, we have our templates.
[00:02:19] And so this is just HTML with some Angular pieces in it that tells Angular how to render a component, more importantly, how to keep rendering the component. So it includes data bindings as well as it allows us to essentially embed other components as children into our parent components.
[00:02:43] So keep that in mind. Just a little mental note is that when you want to make a component available or use a component, it's done via a template. And the upside for this is or one thing that I think Angular has done really well, is prior to Angular, so 1.x, so I guess I will mention it a bit, is we had all these custom events that we could bind to, and it just created a ton of surface area for the framework.
[00:03:17] Well in Angular, what they decided to do is to just simply leverage native DOM events. And so a lot of times, if you want to respond to a click event, you will just simply bind to that native DOM event, and then respond accordingly. So there's also some interesting things in terms of shadow DOM that Angular leverages that allows you to do kind of per component styling.
[00:03:47] And I'm not gonna talk about view and capsulation much, but it is worth mentioning that you can define styles at a component level. And the problem with CSS is the C stands for cascading, and so if you've ever created something, it looks amazing. And you spent hours on this masterpiece, then you turn it off or you turn it over to your team to use.
[00:04:13] And then somebody, some barbarian in some other team sets this H1 tags to 72 font or something and destroys it, that's the plight of cascading stylesheets. And so Angular uses some shadow DOM under the hood to kind of mitigate that. So in this case we are defining our template, external to our component class.
[00:04:41] And this is the recommended way of doing this, and personally and stylistically, I prefer this style than having your template as an external file separate from the class. And the upside to this is that if you have somebody that's strictly doing layout, so if you work with a design team and they're giving you layout, well, you just need to pick up their HTML and essentially put that in proximity.
[00:05:12] Or put them into the template files and then update it. Whereas you can do this inline, and so this is very much how it's done in React, and I think that there's nothing morally wrong about this. I personally, I prefer to have a clean separation between declarative markup and imperative logic.
[00:05:37] But for simple cases, this is an absolutely fine approach, is just to have your template inline to your component class. So not a problem, I certainly am not going to judge you or indict you in any way. But every time I brought this up to a React developer to where it's like, well, what if you have a template that's 400 lines long?
[00:06:05] Well, the response is, if that happens, that's not a React problem, that is a much bigger problem in that your component is too coarse grid. And so they kind of use this as a canary in a coal mine situation where if all of a sudden you're looking at your template and your component class, and it's very, very large or it starts to become unmanageable, it's a good sign that you probably need to create additional tractions.