parent
dd0d822cbc
commit
e258e0f346
|
@ -1,16 +0,0 @@
|
|||
System.register(['angular2/platform/browser', './app.component.1'], function(exports_1) {
|
||||
var browser_1, app_component_1_1;
|
||||
return {
|
||||
setters:[
|
||||
function (browser_1_1) {
|
||||
browser_1 = browser_1_1;
|
||||
},
|
||||
function (app_component_1_1_1) {
|
||||
app_component_1_1 = app_component_1_1_1;
|
||||
}],
|
||||
execute: function() {
|
||||
browser_1.bootstrap(app_component_1_1.AppComponent);
|
||||
}
|
||||
}
|
||||
});
|
||||
//# sourceMappingURL=main.1.js.map
|
|
@ -1,16 +0,0 @@
|
|||
System.register(['angular2/platform/browser', './app.component'], function(exports_1) {
|
||||
var browser_1, app_component_1;
|
||||
return {
|
||||
setters:[
|
||||
function (browser_1_1) {
|
||||
browser_1 = browser_1_1;
|
||||
},
|
||||
function (app_component_1_1) {
|
||||
app_component_1 = app_component_1_1;
|
||||
}],
|
||||
execute: function() {
|
||||
browser_1.bootstrap(app_component_1.AppComponent);
|
||||
}
|
||||
}
|
||||
});
|
||||
//# sourceMappingURL=main.js.map
|
|
@ -113,8 +113,7 @@ include ../../../../_includes/_util-fns
|
|||
The component itself is usually the expression *context*, in which case
|
||||
the template expression usually references that component.
|
||||
|
||||
The expression context can include objects <!-- CHECK: is that an ok wording change? -->
|
||||
other than the component.
|
||||
The expression context can include objects other than the component.
|
||||
A [local template variable](#local-vars) is one such alternative context object.
|
||||
|
||||
|
||||
|
@ -785,8 +784,6 @@ code-example(format="", language="html").
|
|||
`ngModelChange` output property.
|
||||
That’s a specific example of a more general pattern in which Angular matches `[(x)]` to an `x` input property
|
||||
for property binding and an `xChange` output property for event binding.
|
||||
<!-- TODO: We haven't talked about input and output properties before on
|
||||
this page (and barely mentioned them before in the Forms page). Introduce them better. -->
|
||||
:marked
|
||||
Is `[(ngModel)]` all we need? Is there ever a reason to fall back to its expanded form?
|
||||
|
||||
|
@ -801,7 +798,6 @@ code-example(format="", language="html").
|
|||
figure.image-display
|
||||
img(src='/resources/images/devguide/template-syntax/ng-model-anim.gif' alt="NgModel variations")
|
||||
:marked
|
||||
<!-- TODO: Update image to use camelCase instead of kabob-case -->
|
||||
|
||||
.l-main-section
|
||||
:marked
|
||||
|
@ -1131,7 +1127,6 @@ figure.image-display
|
|||
.alert.is-important
|
||||
:markdown
|
||||
Remember: All **components** are **directives**.
|
||||
|
||||
:marked
|
||||
.l-sub-section
|
||||
:marked
|
||||
|
@ -1185,7 +1180,9 @@ figure.image-display
|
|||
*Output* properties expose event producers, such as `EventEmitter` objects.
|
||||
|
||||
The terms _input_ and _output_ reflect the perspective of the target directive.
|
||||
|
||||
figure.image-display
|
||||
img(src='/resources/images/devguide/template-syntax/input-output.png' alt="Inputs and outputs")
|
||||
:marked
|
||||
`HeroDetailComponent.hero` is an **input** property from the perspective of `HeroDetailComponent`
|
||||
because data flows *into* that property from a template binding expression.
|
||||
|
||||
|
|
Binary file not shown.
After Width: | Height: | Size: 12 KiB |
Loading…
Reference in New Issue