Multiple Components 4.0
AppComponent is doing everything at the moment.
In the beginning, it showed details of a single hero.
Then it became a master/detail form with both a list of heroes and the hero detail.
Soon there will be new requirements and capabilities.
You can’t keep piling features on top of features in one component; that’s not maintainable.
You’ll need to break it up into sub-components, each focused on a specific task or workflow.
AppComponent could become a simple shell that hosts those sub-components.
In this page, you’ll take the first step in that direction by carving out the hero details into a separate, reusable component.
When you’re done, the app should look like this
Where you left off
Before getting started on this page, verify that you have the following structure from earlier in the Tour of Heroes. If not, go back to the previous pages.
Make a hero detail component
Create a file named
This file will hold the new
The component class name should be written in upper camel case and end in the word “Component”. The hero detail component class is
The component file name should be in snake case —lowercase with underscore separation—and end in
HeroDetailComponentclass goes in the
Internal implementation files should be placed under
lib/src. See the pub package layout conventions for details.
Start writing the
HeroDetailComponent as follows:
@Component annotation provides the Angular metadata for the component.
The CSS selector name,
hero-detail, will match the element tag
that identifies this component within a parent component’s template.
Near the end of this tutorial page,
you’ll add a
<hero-detail> element to the
Hero detail template
To move the hero detail view to the
cut the hero detail content from the bottom of the
and paste it into a new
template argument of the
HeroDetailComponent has a hero, not a selected hero.
Replace the word, “selectedHero”, with the word, “hero”, everywhere in the template.
When you’re done, the new template should look like this:
Add the hero property
HeroDetailComponent template binds to the component’s
Add that property, along with the requisite import,
The hero property is an input property
Later in this page,
AppComponent will tell the child
HeroDetailComponent which hero to display
by binding its
selectedHero to the
hero property of the
The binding will look like this:
Putting square brackets around the
hero property, to the left of the equal sign (=),
makes it the target of a property binding expression.
You must declare a target binding property to be an input property.
Otherwise, Angular rejects the binding and throws an error.
hero is an input property by annotating it with
Read more about input properties in the Attribute Directives page.
That’s it. The
hero property is the only thing in the
All it does is receive a hero object through its
hero input property and then bind to that property with its template.
Here’s the complete
Add HeroDetailComponent to the AppComponent
AppComponent is still a master/detail view.
It used to display the hero details on its own, before you cut out that portion of the template.
Now it will delegate to the
Start by importing the
AppComponent can refer to it.
hero-detail is the CSS
That’s the tag name of the element that represents the
<hero-detail> element near the bottom of the
where the hero detail view used to be.
Coordinate the master
AppComponent with the
by binding the
selectedHero property of the
hero property of the
Now every time the
selectedHero changes, the
HeroDetailComponent gets a new hero to display.
AppComponent template should look like this:
The detail should update every time the user picks a new hero. It’s not happening yet! Click a hero. No details. If you look for an error in the console of the browser development tools. No error.
It is as if Angular were ignoring the new tag. That’s because it is ignoring the new tag.
The directives list
A browser ignores HTML tags and attributes that it doesn’t recognize. So does Angular.
HeroDetailComponent, and you’ve used
the template, but you haven’t told Angular about it.
Just as you’ve done for the built-in Angular directives, tell Angular
about the hero detail component by listing it in the metadata
list. You don’t need
formDirectives anymore, so delete it and the
angular_forms import at the top of the file:
open_in_browser Refresh the browser. The app works!
App design changes
As before, whenever a user clicks on a hero name,
the hero detail appears below the hero list.
But now the
HeroDetailComponent is presenting those details.
Refactoring the original
AppComponent into two components yields benefits, both now and in the future:
- You simplified the
AppComponentby reducing its responsibilities.
- You can evolve the
HeroDetailComponentinto a rich hero editor without touching the parent
- You can evolve the
AppComponentwithout touching the hero detail view.
- You can reuse the
HeroDetailComponentin the template of some future parent component.
Review the app structure
Verify that you have the following structure:
Here are the code files discussed in this page.
The road you’ve travelled
Here’s what you achieved in this page:
- You created a reusable component.
- You learned how to make a component accept input.
- You learned to declare the app directives in a
- You learned to bind a parent component to a child component.
Your app should look like this
The road ahead
The Tour of Heroes app is more reusable with shared components,
but its (mock) data is still hard coded within the
That’s not sustainable.
Data access should be refactored to a separate service
and shared among the components that need data.
You’ll learn to create services in the next tutorial page.