Introduction to Angular Components
Components are like the LEGO pieces of an Angular application. If you don't know how to put them together properly, you're not going to be able to build anything cool. Over the next 10 minutes or so, I'll show you all of the basics in Angular components and how to piece them together in an application.
This video is beginner level, so if you know a little bit about JavaScript and web development, you should be okay. If you're new to the channel, make sure to like and subscribe and grab the full write-up from angularfirebase.com.
The first question we need to answer is what is a component in the first place? And I think the most simple answer to this question is that it's just a controller for the user interface. As a developer, you write components to control how your app is experienced by end-users. To show you this in practice, I'm opening a brand new Angular 6 app that was generated with the CLI. Then I'm generating a new component called home, which you'll notice creates four different files in the app directory. The vast majority of the logic that you'll write will be in the home component's TS file.
The component itself is just a TypeScript class, but it uses this component decorator to sprinkle in some Angular magic.
Property and Event Binding
The most important thing is that it allows us to bind data from this TypeScript file to the HTML template. The first thing I want to show you is how to bind TypeScript code to your HTML. Let's define a property on this class called clicked that defaults to false. Now let's go into the HTML and let's imagine we have a button that we want to disable after it's been clicked. We can bind our TypeScript data to this attribute in HTML by wrapping it in square brackets. disabled isn't something Angular provides, it's an actual attribute on the HTML element which I'm looking at here in the Mozilla documentation.
The special thing about Angular is that we can wrap this attribute in square brackets and then bind it to our TypeScript. So instead of just passing it a boolean value like false, we can actually pass it our clicked property, which we can then toggle on our TypeScript as needed. It's currently set to false, so we should be able to serve our app and the button should be clickable, which it is. If we go into TypeScript and change our clicked property to true, you'll see that the button is now disabled and unclickable.
In addition to attributes, we can also bind to events that happen in the HTML. So let's say we want to change this to disabled after it's been clicked once. We can use parentheses to bind to the click event on this button and then we'll pass it a function that we'll define in our TypeScript to handle this event.
Now we can switch back to TypeScript and define this event handler method. We currently have the clicked property set to false, but we want to set that to true once the button is clicked, which we can do by calling this.clicked = true. When we click the button this handler will fire and then the button becomes disabled because it flips that property to true.
That's how you bind to events and attributes in Angular.
Interpolation and Component Loading
But one other fundamental thing is interpolation. And basically all that means is we're taking a raw value from our TypeScript and rendering it out in the HTML. So for example, let's say we have the title here that shows the Angular version that we're currently running. So the title is just a string value that gets created dynamically and then we can go into our HTML and use the handlebar syntax to interpolate it into the template. If we reload the browser it should show us that we're running in Angular 6 for this project.
So now that we have a working component, how do we actually use it within the context of our Angular application? The most basic way is to declare it in the HTML with its selector, which in this case is just app-home. If we go into this project's app component, we can just declare our app home page there and it will be rendered out like it's just a regular HTML element. But we can also load it with the router and have it appear where this router outlet is based on a certain URL path. Check out episode 113 to learn all about the router, but the most basic use case is that we set up a path and then we point this path to our component. If we reload the app in the browser, you'll see it looks exactly the same, but if we open the Augury plugin and go to the router tree, you can see that it's being loaded by the router instead of just the HTML directly.
You can also load components dynamically but without changing the route. A common use case would be like a pop-up or a modal window. This technique is used frequently in the Ionic framework, for example, the alerts controller will dynamically load an entry component whenever the button is clicked. And lastly, the cool new way to load a component is with Angular Elements, which allows you to convert it to a regular web component and then use it outside of Angular completely. So you could just drop it into a regular HTML page, which you can learn all about in episode 102.
Mastering Built-in Directives
The next thing we're going to look at are directives, and a directive is basically just like a component but without its own HTML or CSS. Instead, it attaches to a host element and changes the behavior of it. To demonstrate this, I've added an object called boat with some dummy data to our component. Then perhaps the most useful built-in directive in Angular is ngIf, and any directive that starts with a star means it's a structural directive and controls how elements are rendered in the DOM. In this case, we're attaching an ngIf to a div, and it will only render this div if the right-hand side resolves to true. So going back to our clicks property, we're only going to show this boat data if the button has been clicked. When we open the app, you can see that it looks just like it did before, but when we click the button it displays our boat data.
You'll end up using ngIf all the time in Angular, and there's one other directive that you'll use very frequently as well, which is ngFor. You can use it to loop over an array of data. So let's imagine we have an array with multiple boats in it. We've already mapped out how we want each boat to be displayed, but instead of using ngIf here, we can replace it with ngFor. Then we'll iterate over the boats array by saying let boat of boats. Then the div that this directive is attached to will be rendered for each item in that array. If we open the app, you can see we now have multiple boats utilizing the same presentation logic.
So those are super powerful, but another thing you often want to do is display different CSS classes conditionally based on some logic in your TypeScript. Just as a basic example, let's imagine we have a green and red CSS class. We can use the ngClass directive to control which CSS class gets applied to the h1 title based on the name of the boat. So we'll pass the directive an object where the left-hand side of each object property is the CSS class we want to apply. Then the value, or the right side, is an expression that resolves to true or false, which in this case will either be boat.name === 'Starfire' or boat.name === 'Oracle'. Now we get a different color for each title based on this logic.
Creating a Custom Directive
So far we've only looked at built-in directives in Angular, but you can also build your own custom directives. Let's go ahead and build our own with the Angular CLI by running ng generate directive, which we'll call magnifier, that will increase the size of an image when it's hovered over. Overall this looks pretty similar to a component, but the key difference is that there is no HTML template or CSS styles. Instead, it's used as an attribute on an HTML element.
This particular directive will be used to modify the width of an image element. So we can bind to the host element's width by using the HostBinding decorator. Then any image that uses this directive will start with a width of 200. Then we also want to listen to the mouseenter event to know when the user has hovered over the image with their mouse. With that, we can use the HostListener decorator, pass in the DOM event that we want to listen to, and then define a function to handle this event. In this case, what we want to do is really simple: just increase the width from 200 to 300. Now we'll switch back to the HTML in our component, and we currently have an image in there that displays the boat image with a width of 200. Let's go ahead and take this out and replace it with the appMagnifier directive. If we go back to our app and hover over the images, you'll see that they're resized as soon as we hover over them.
Not the most useful thing in the world, but you get the idea of how you can use components and directives together to write really dry, reusable code. There's another mechanism in Angular that helps us write reusable code called pipes. A pipe is always used in an interpolated value in the HTML. So let's imagine we have a big number here. We can use the built-in number pipe to round this down to three decimals. Angular has some useful built-in pipes, but the real power comes when you start building your own custom pipes. And chances are somebody's already written the code that you need for your use case, so make sure to check out the Angular pipes Github repo for a full list of examples.
There's one really special pipe that I want to talk about now, which is the async pipe. In a web application, you're commonly fetching data asynchronously as a promise or an observable, and the async pipe allows you to do this automatically in a predictable way directly in the HTML. In this example, I'm converting our boats array into an observable by using the RxJS of method. So now it becomes an observable object, so our regular ngFor loop isn't going to work. What we can do is simply add the async pipe to our for loop and now it's going to convert that observable to an array by subscribing to it. And in addition, it also unsubscribes when this component is destroyed. That's a whole 'nother subject on RxJS, but just know that it's a very useful mechanism for simplifying your Angular code. In a real app, we'd probably be fetching these boats asynchronously from a database and the async pipe allows us to treat them more like a synchronous plain JavaScript array.
At its core, a pipe is very simple. It's just a function that takes in a value and then spits out another value. Each of our boats has a year property on it. Let's say we want to only display the last two digits in that four-digit year. All we have to do is go into our custom pipe and then implement this transform method. The value represents whatever value is inside the handlebar syntax in your HTML, then the value you return is what you want to be shown in the HTML. In this case, we'll convert the number to a string and then grab the last two elements on that string. Then we can go add it to the boat year in our HTML and then if we reopen the app, we'll see that we only get the last two numbers on the year.
Best Practice: Avoid Direct DOM Manipulation
So now that you know a lot about components, pipes, and directives, I want to talk about a concept that's really important for Angular developers, and that's never touch the DOM. If you're an experienced JavaScript developer, you're probably used to doing something like this where you call document.querySelector, then grab some element in the DOM and change its innerHTML. And when you're building a progressive web app, this code will work perfectly fine because the DOM exists in a web app. But if you write code like this and you ever want to do server-side rendering or build a native mobile app, this code will not work because the DOM does not exist on other platforms. So now you know why the use of libraries like jQuery are generally discouraged in Angular.
The Component Lifecycle
Now let's switch gears into the component lifecycle. A component is just a class, so the very first thing that happens in its lifecycle is the constructor is fired. But components have relationships with other components and they have bindings that are initialized in the HTML, so things get a little bit more complex in Angular. You typically don't do anything in the constructor except add your dependencies, and that's because your property bindings aren't guaranteed to be available until you run ngOnInit, which is the first time change detection runs in this component.
So the onInit lifecycle hook is where you do all of your setup. Maybe you're fetching from an API or you're setting up a reactive form or something along those lines. I'll go ahead and add our boats observable to ngOnInit just to simulate it coming from a database or API. The very last thing to happen to a component is that it's destroyed, which triggers the onDestroy lifecycle hook. This is where you do any teardown for your component. In Angular, that is commonly unsubscribing from an observable to prevent things like memory leaks and performance issues.
onInit is by far the most common hook that you'll use, but if you have child views inside of your component, you might also want to use afterViewInit, which will ensure that your child views are loaded as well.
How Change Detection Works
Now that segues into a really important concept in Angular, which is change detection. Behind the scenes, Angular is using something called zone.js that will listen for any events or asynchronous activity in your app and then re-render components as needed. You can determine when change detection is happening by using this doCheck lifecycle hook. You wouldn't normally use this to do anything significant, but it is useful for debugging at times. If you're building an interactive app, this lifecycle hook will be triggered constantly. You can see we get the first console log when the component is initialized. That's when the ngOnInit lifecycle hook runs, and then as we hover around, different events take place and that triggers change detection and the console log in the browser.
Smart vs. Dumb Components Pattern
So now I want to segue into a concept that is also common in other JavaScript frameworks like React and Vue, and that's smart components versus dumb components, or also commonly called stateful versus stateless or container versus presentational. And basically, all this boils down to is a separation of concerns to make your code predictable. A smart component is generally a page or container that controls how things work throughout the app, while the dumb component is only concerned with presentation logic.
I have generated a new component called boat that will be our dumb component. It's going to take the data from this ngFor loop and extract it into its own isolated presentational component. This allows the parent component to focus on more low-level things like synchronizing the state of the app and fetching the items from the database. As your app grows in complexity, this just becomes an easier way to rationalize what's happening. So the home component is a container that fetches the data, while the boat component is only concerned with presenting the data in the UI.
Conclusion
There's a ton of other things we can talk about with Angular components, but many of those you'll see in practice as we build out different features on this channel. I'm going to go ahead and wrap things up there. If this video helped you, please like and subscribe. And if you want to build more advanced, real-world features, consider becoming a pro member at angularfirebase.com. You'll get exclusive pro videos every week, plus a copy of the Angular Firebase Survival Guide. Thanks for watching, and I'll talk to you soon.
