Important Note: Due to our Monday closure in observance of Martin Luther King Day, this week has more Thursday homework than usual. However, because you'll work on this Friday's independent project for the next two Fridays, it will not be graded for concepts introduced in Thursday lessons until after next week's independent project submission.
So far, all of our application's functionality resides in a single root component. However, placing everything in the root component is not best practice. Now that our application has grown, we'll organize our code into multiple components, each with their own distinct responsibility and purpose.
In this lesson we'll discuss best practices for structuring an Angular application, including how to determine when to use multiple components, how components work together in an application, and how to plan an application's component structure. We'll create a plan for re-organizing our application into multiple components. Then we'll create the first of our new components in this lesson. We'll build out the rest in upcoming lessons.
Angular applications are a series of components. They begin with a top-level root component. The root component houses all other components in the application.
Components that live inside in another component are often known as child components or nested components.
These child components may also contain their own child components. This allows us to make our code more modular and reusable, which is a best practice.
So when should we make a new component and when should we add functionality to an existing component? There are several important best practices to follow:
Ideally, components should have one sole responsibility. Common responsibilities include displaying items, creating new items, or modifying existing items.
Separating our application into components with clear, distinct purposes makes it easier to debug and makes it easier for other developers to jump into our code base.
Components can be reused throughout an application. Will your app require the same functionality and content in multiple spots? That's an indication a component should be used.
For instance, if we were to build an address book application with many contacts, we'd probably want each contact entry to have the same functionality and appearance. We could add a
contact_detail component that includes an edit form, uniform styling and appearance, a 'delete' button, and so on. These pieces of functionality and display can be packaged in a single component and then repeated for each Contact in the address book.
Now that we have the skillset necessary to create larger, more complex Angular applications, you should always consider the structure of your application before beginning to code. Let's create a plan to refactor our application into multiple components.
We'll start with user stories. Remember, user stories are essentially a list of requested features.
For instance, here are the three primary user stories for our to do application:
Now that we have a set of user stories, we can determine how many components we'll need.
We already know that we need a root component. The root component resides in the root module. The root component will contain all of our child components. Its sole responsibility is housing nested components and passing them data they require.
This is the basic structure of our application:
Let's walk through our user stories to determine how we can better organize our application with additional components.
The first user story reads "As a user, I want to see a list of tasks."
Remember, each component should have a distinct, dedicated responsibility. Our root component will be responsible for housing child components and passing along data. That's its dedicated responsibility. We shouldn't rely on it to list
Instead, we'll create a new
TaskListComponent to handle displaying our list of
Tasks. It will reside directly within our root component.
After implementing a
TaskListComponent, our application structure will look like this:
Let's consider the next user story: "As a user, I want to edit individual tasks."
While editing a
Task requires multiple steps (displaying an edit form, making changes and hiding the form again), this can still be considered a single responsibility in the application.
We'll need a dedicated component to handle it. We'll create an
EditTaskComponent to manage the process of editing tasks. It will also reside in the root component:
The final user story above reads: "As a user, I want to add new tasks to the list. "
Tasks are still hardcoded and we can't create new ones through our application yet. However, we'll add this functionality in a future lesson and we'll need a component for
Let's plan on calling this
NewTaskComponent. It'll contain a form to enter details for a new
Task. It will also reside directly in the root component:
We'll eventually add other features like filtering
Tasks based on their priority and marking them as done, but for now we'll focus on these three new components.
It's important to plan out the structure of an Angular application. While your plan may change as you develop, knowing the components you'll require and where they'll be located can make the development process smoother. Moving forward, make sure to draft the component structure of new applications before you start coding.
Now that we've planned our application, here are the additional components we'll need:
TaskListComponent: List all
EditTaskComponent: Manage editing and updating
Tasks, including hiding and showing the edit form.
NewTaskComponent: Add functionality that will allow us to add new
Tasks directly through our application.
In this next lesson, we'll build the
TaskListComponent. Upcoming lessons will walk through the creation of the other two components.