{ "id": "guide/component-interaction", "title": "Component interaction", "contents": "\n\n\n
This cookbook contains recipes for common component communication scenarios\nin which two or more components share information.\n
\n\nSee the
HeroChildComponent
has two input properties,\ntypically adorned with @Input() decorator.
The second @Input
aliases the child component property name masterName
as 'master'
.
The HeroParentComponent
nests the child HeroChildComponent
inside an *ngFor
repeater,\nbinding its master
string property to the child's master
alias,\nand each iteration's hero
instance to the child's hero
property.
The running application displays three heroes:
\nE2E test that all children were instantiated and displayed as expected:
\nUse an input property setter to intercept and act upon a value from the parent.
\nThe setter of the name
input property in the child NameChildComponent
\ntrims 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:
E2E tests of input property setter with empty and non-empty names:
\nDetect and act upon changes to input property values with the ngOnChanges()
method of the OnChanges
lifecycle hook interface.
You may prefer this approach to the property setter when watching multiple, interacting input properties.
\nLearn about ngOnChanges()
in the 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.
Here's the output of a button-pushing sequence:
\nTest that both input properties are set initially and that button clicks trigger\nthe expected ngOnChanges
calls and values:
The child component exposes an EventEmitter
property with which it emits
events when something happens.\nThe parent binds to that event property and reacts to those events.
The child's EventEmitter
property is an output property,\ntypically adorned with an @Output() decorator\nas seen in this VoterComponent
:
Clicking a button triggers emission of a true
or false
, the boolean payload.
The parent VoteTakerComponent
binds an event handler called onVoted()
that responds to the child event\npayload $event
and updates a counter.
The framework passes the event argument—represented by $event
—to the handler method,\nand the method processes it:
Test that clicking the Agree and Disagree buttons update the appropriate counters:
\nA parent component cannot use data binding to read child properties\nor invoke child methods. You can do both\nby creating a template reference variable for the child element\nand then reference that variable within the parent template\nas seen in the following example.
\n\nThe following is a child CountdownTimerComponent
that repeatedly counts down to zero and launches a rocket.\nIt has start
and stop
methods that control the clock and it displays a\ncountdown status message in its own template.
The CountdownLocalVarParentComponent
that hosts the timer component is as follows:
The parent component cannot data bind to the child's\nstart
and stop
methods nor to its seconds
property.
You can place a local variable, #timer
, on the tag <countdown-timer>
representing the child component.\nThat gives you a reference to the child component and the ability to access\nany of its properties or methods from within the parent template.
This example wires parent buttons to the child's start
and stop
and\nuses interpolation to display the child's seconds
property.
Here we see the parent and child working together.
\nTest that the seconds displayed in the parent template\nmatch the seconds displayed in the child's status message.\nTest also that clicking the Stop button pauses the countdown timer:
\nThe local variable approach is simple and easy. But it is limited because\nthe parent-child wiring must be done entirely within the parent template.\nThe parent component itself has no access to the child.
\nYou can't use the local variable technique if an instance of the parent component class\nmust read or write child component values or must call child component methods.
\nWhen the parent component class requires that kind of access,\ninject the child component into the parent as a ViewChild.
\nThe following example illustrates this technique with the same\nCountdown Timer example.\nNeither its appearance nor its behavior will change.\nThe child CountdownTimerComponent is the same as well.
\nThe switch from the local variable to the ViewChild technique\nis solely for the purpose of demonstration.
\nHere is the parent, CountdownViewChildParentComponent
:
It takes a bit more work to get the child view into the parent component class.
\nFirst, you have to import references to the ViewChild
decorator and the AfterViewInit
lifecycle hook.
Next, inject the child CountdownTimerComponent
into the private timerComponent
property\nvia the @ViewChild
property decoration.
The #timer
local variable is gone from the component metadata.\nInstead, bind the buttons to the parent component's own start
and stop
methods and\npresent the ticking seconds in an interpolation around the parent component's seconds
method.
These methods access the injected timer component directly.
\nThe ngAfterViewInit()
lifecycle hook is an important wrinkle.\nThe timer component isn't available until after Angular displays the parent view.\nSo it displays 0
seconds initially.
Then Angular calls the ngAfterViewInit
lifecycle hook at which time it is too late\nto update the parent view's display of the countdown seconds.\nAngular's unidirectional data flow rule prevents updating the parent view's\nin 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\nthat it takes future values from the timer component.
Use the same countdown timer tests as before.
\n\n\nA parent component and its children share a service whose interface enables bi-directional communication\nwithin the family.
\nThe scope of the service instance is the parent component and its children.\nComponents outside this component subtree have no access to the service or their communications.
\nThis MissionService
connects the MissionControlComponent
to multiple AstronautComponent
children.
The MissionControlComponent
both provides the instance of the service that it shares with its children\n(through the providers
metadata array) and injects that instance into itself through its constructor:
The AstronautComponent
also injects the service in its constructor.\nEach 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.\nThis is a memory-leak guard step. There is no actual risk in this app because the\nlifetime of a AstronautComponent
is the same as the lifetime of the app itself.\nThat would not always be true in a more complex application.
You don't add this guard to the MissionControlComponent
because, as the parent,\nit controls the lifetime of the MissionService
.
The History log demonstrates that messages travel in both directions between\nthe parent MissionControlComponent
and the AstronautComponent
children,\nfacilitated by the service:
Tests click buttons of both the parent MissionControlComponent
and the AstronautComponent
children\nand verify that the history meets expectations: