Understanding Component Architecture: Refactoring an Angular App

This article is part 2 of the SitePoint Angular 2+ Tutorial on how to create a CRUD App with the Angular CLI.
In part one we learned how to get our Todo application up and running and deploy it to GitHub pages. This worked just fine, but unfortunately the whole app was crammed into a single component.
In this article (part two) we will examine a more modular component architecture. We will look at how to break this single component into a structured tree of smaller components that are easier to understand, re-use and maintain.
You don’t need to have followed part one of this tutorial, for part two to make sense. You can simply grab a copy of our repo, checkout the code from part one, and use that as a starting point. This is explained in more detail below.
A Quick Recap
So let’s look at what we covered in part one in slightly more detail. We learned how to:

initialize our Todo application using the Angular CLI
create a Todo class to represent individual todos
create a TodoDataService service to create, update and remove todos
use the AppComponent component to display the user interface
deploy our application to GitHub pages

The application architecture of part 1 looked like this:

The components we discussed are marked with a red border.
In this second article we will delegate some of the work that AppComponent is doing to smaller components that are easier to understand, re-use and maintain.
We will create:

a TodoListComponent to display a list of todo’s
a TodoListItemComponent to display a single todo
a TodoListHeaderComponent to create a new todo
a TodoListFooterComponent to show how many todo’s are left

By the end of this article, you will understand:

the basics of Angular component architecture
how you can pass data into a component using property bindings
how you can listen for events emitted by a component using event listeners
why it is a good practice to split components into smaller reusable components
the difference between smart and dumb components and why keeping components dumb is a good practice

So let’s get started!
Up and Running
The first thing you will need to follow along with this article is the latest version of the Angular CLI. You can install this with the following command:
npm install -g @angular/cli@latest

If you need to remove a previous version of of the Angular CLI, here’s how:
npm uninstall -g @angular/cli angular-cli
npm cache clean
npm install -g @angular/cli@latest

After that you’ll need a copy of the code from part one. This is available at https://github.com/sitepoint-editors/angular-todo-app. Each article in this series has a corresponding tag in the repository so you can switch back and forth between the different states of the application.
The code that we ended with in part one and that we start with in this article is tagged as part-1. The code that we end this article with is tagged as part-2.
You can think of tags like an alias to a specific commit id. You can switch between them using git checkout. You can read more on that here.
So, to get up and running (the the latest version of the Angular CLI installed) we would do:
git clone git@github.com:sitepoint-editors/angular-todo-app.git
cd angular-todo-app
npm install
git checkout part-1
ng serve

Then visit http://localhost:4200/. If all is well, you should see the working Todo app.
The Original AppComponent
Let’s open src/app/app.component.html and have a look at the AppComponent that we finished with in part one: