In the last lesson we created our first child component. The
TaskListComponent resides in our
AppComponent and is responsible for listing all
Tasks. However, the "edit" buttons don't work yet. This is because the
TaskListComponent doesn't know what
editTask() is. The logic for this method remains in our
We don't want to move
TaskListComponent because our components each have a single, dedicated responsibility. As we discussed in the last lesson, an
EditTaskComponent will handle updating
However, we can't remove the edit button from the
TaskListComponent, either, because we need a button to appear next to each
Task in the list so the user can specify which task should be edited.
How can we resolve this so our components 'communicate' with one another? In this lesson we'll learn about the "Data down, actions up". In the next two lessons, we'll use
@Outputs to send and receive information between components.
Data down, actions up is a programming principle used in multiple frameworks such as Angular and Ember. Data is stored at the "top" in the parent component and passed downward to child components that may require it. Meanwhile, actions are triggered in child components and passed up to the parent component, which manages changes such as updating data.
Consider the diagram we created while planning our application's component structure:
Let's take a look at just the components from the diagram above so we can visualize the relationship between the parent (root component) and its children:
The parent component holds all data and passes the data downward to other components if needed. In our case, this is the collection of
Task objects for our To Do List.
If any child components require that data, they request it from the root component. The data then moves downward from the parent component into that child component.
For example, we know our
TaskListComponent requires access to our
Task data to display our list of
Tasks. In a "data down, actions up" design, our list of
Tasks resides in the parent and is passed down to the child.
This pattern continues through as many "generations" of components as necessary. For instance, if
TaskListComponent had a child component of its own, it could continue passing data it receives from its parent down to its child.
Actions move upward. When actions are triggered in child components, these actions are sent upward to the parent. The parent may then alter data or perform other actions accordingly.