Component Interaction: Pass Data From Parent To Child With Input Binding
Component Interaction: Pass Data From Parent To Child With Input Binding
{@a top}
This cookbook contains recipes for common component communication scenarios in which two or more
components share information. {@a toc}
See the .
{@a parent-to-child}
The second @Input aliases the child component property name masterName as 'master' .
Test it
E2E test that all children were instantiated and displayed as expected:
Back to top
{@a parent-to-child-setter}
The setter of the name input property in the child NameChildComponent trims the whitespace from a
name and replaces an empty value with default text.
Here's the NameParentComponent demonstrating name variations including a name with all spaces:
Test it
E2E tests of input property setter with empty and non-empty names:
Back to top
{@a parent-to-child-on-changes}
You may prefer this approach to the property setter when watching multiple, interacting input properties. Learn
about `ngOnChanges()` in the [LifeCycle Hooks](guide/lifecycle-hooks) chapter.
This VersionChildComponent detects changes to the major and minor input properties and
composes a log message reporting these changes:
The VersionParentComponent supplies the minor and major values and binds buttons to
methods that change them.
Test it
Test that both input properties are set initially and that button clicks trigger the expected ngOnChanges calls
and values:
Back to top
{@a child-to-parent}
The child's EventEmitter property is an output property, typically adorned with an @Output decoration
as seen in this VoterComponent :
The parent VoteTakerComponent binds an event handler called onVoted() that responds to the child
event payload $event and updates a counter.
The framework passes the event argument—represented by $event —to the handler method, and the
method processes it:
Test it
Test that clicking the Agree and Disagree buttons update the appropriate counters:
Back to top
The parent component cannot data bind to the child's start and stop methods nor to its seconds
property.
You can place a local variable, #timer , on the tag <countdown-timer> representing the child
component. That gives you a reference to the child component and the ability to access any of its properties or
methods from within the parent template.
This example wires parent buttons to the child's start and stop and uses interpolation to display the
child's seconds property.
{@a countdown-tests}
Test it
Test that the seconds displayed in the parent template match the seconds displayed in the child's status
message. Test also that clicking the Stop button pauses the countdown timer:
Back to top
{@a parent-to-view-child}
You can't use the local variable technique if an instance of the parent component class must read or write child
component values or must call child component methods.
When the parent component class requires that kind of access, inject the child component into the parent as a
ViewChild.
The following example illustrates this technique with the same Countdown Timer example. Neither its
appearance nor its behavior will change. The child CountdownTimerComponent is the same as well.
The switch from the *local variable* to the *ViewChild* technique is solely for the purpose of demonstration.
It takes a bit more work to get the child view into the parent component class.
First, you have to import references to the ViewChild decorator and the AfterViewInit lifecycle
hook.
Next, inject the child CountdownTimerComponent into the private timerComponent property via the
@ViewChild property decoration.
The #timer local variable is gone from the component metadata. Instead, bind the buttons to the parent
component's own start and stop methods and present the ticking seconds in an interpolation around
the parent component's seconds method.
The ngAfterViewInit() lifecycle hook is an important wrinkle. The timer component isn't available until
after Angular displays the parent view. So it displays 0 seconds initially.
Then Angular calls the ngAfterViewInit lifecycle hook at which time it is too late to update the parent
view's display of the countdown seconds. Angular's unidirectional data flow rule prevents updating the parent
view's in the same cycle. The app has to wait one turn before it can display the seconds.
Use setTimeout() to wait one tick and then revise the seconds() method so that it takes future
values from the timer component.
Test it
Back to top
{@a bidirectional-service}
The scope of the service instance is the parent component and its children. Components outside this
component subtree have no access to the service or their communications.
The MissionControlComponent both provides the instance of the service that it shares with its children
(through the providers metadata array) and injects that instance into itself through its constructor:
The AstronautComponent also injects the service in its constructor. Each AstronautComponent is a
child of the MissionControlComponent and therefore receives its parent's service instance:
Notice that this example captures the `subscription` and `unsubscribe()` when the `AstronautComponent` is
destroyed. This is a memory-leak guard step. There is no actual risk in this app because the lifetime of a
`AstronautComponent` is the same as the lifetime of the app itself. That *would not* always be true in a more
complex application. You don't add this guard to the `MissionControlComponent` because, as the parent, it
controls the lifetime of the `MissionService`.
The History log demonstrates that messages travel in both directions between the parent
MissionControlComponent and the AstronautComponent children, facilitated by the service:
Test it
Tests click buttons of both the parent MissionControlComponent and the AstronautComponent
children and verify that the history meets expectations:
Back to top