Skip to content
This repository was archived by the owner on Dec 4, 2017. It is now read-only.

docs(user-input): replace "expression" w/ "statement" in TS doc #714

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 12 additions & 12 deletions public/docs/ts/latest/guide/user-input.jade
Original file line number Diff line number Diff line change
Expand Up @@ -14,19 +14,19 @@ include ../../../../_includes/_util-fns
We can use [Angular event bindings](./template-syntax.html#event-binding)
to respond to [any DOM event](https://developer.mozilla.org/en-US/docs/Web/Events).

The syntax is simple. We assign a template expression to the DOM event name, surrounded in parentheses.
The syntax is simple. We surround the DOM event name in parentheses and assign a quoted template statement to it.
As an example, here's an event binding that implements a click handler:
+makeExample('user-input/ts/app/click-me.component.ts', 'click-me-button')(format=".", language="html")

<a id="click"></a>
:marked
The `(click)` to the left of the equal sign identifies the button's click event as the **target of the binding**.
The text within quotes on the right is the **template expression** in which we
respond to the click event by calling the component's `onClickMe` method. A [template expression](./template-syntax.html#template-expressions) is a subset
of JavaScript with a few added tricks.
The text within quotes on the right is the **template statement** in which we
respond to the click event by calling the component's `onClickMe` method. A [template statement](./template-syntax.html#template-statements) is a subset
of JavaScript with restrictions and a few added tricks.

When writing a binding we must be aware of a template expression's **execution context**.
The identifiers appearing within an expression belong to a specific context object.
When writing a binding we must be aware of a template statement's **execution context**.
The identifiers appearing within an statement belong to a specific context object.
That object is usually the Angular component that controls the template ... which it definitely is
in this case because that snippet of HTML belongs to the following component:

Expand Down Expand Up @@ -112,8 +112,8 @@ figure.image-display
Angular only updates the bindings (and therefore the screen)
if we do something in response to asynchronous events such as keystrokes.

That's why we bind the `keyup` event to an expression that does ... well, nothing.
We're binding to the number 0, the shortest expression we can think of.
That's why we bind the `keyup` event to an statement that does ... well, nothing.
We're binding to the number 0, the shortest statement we can think of.
That is all it takes to keep Angular happy. We said it would be clever!
:marked
That local template variable is intriguing. It's clearly easier to get to the textbox with that
Expand All @@ -131,14 +131,14 @@ figure.image-display
## Key event filtering (with `key.enter`)
Perhaps we don't care about every keystroke.
Maybe we're only interested in the input box value when the user presses Enter, and we'd like to ignore all other keys.
When we bind to the `(keyup)` event, our event handling expression hears *every keystroke*.
When we bind to the `(keyup)` event, our event handling statement hears *every keystroke*.
We could filter the keys first, examining every `$event.keyCode`, and update the `values` property only if the key is Enter.

Angular can filter the key events for us. Angular has a special syntax for keyboard events.
We can listen for just the Enter key by binding to Angular's `keyup.enter` pseudo-event.

Only then do we update the component's `values` property. (In this example,
the update happens inside the event expression. A better practice
the update happens inside the event binding statement. A better practice
would be to put the update code in the component.)
+makeExample('user-input/ts/app/keyup.components.ts', 'key-up-component-3' ,'app/keyup.components.ts (v3)')(format=".")
:marked
Expand Down Expand Up @@ -198,7 +198,7 @@ figure.image-display
Instead, we grab the input box *value* and pass *that* to `addHero`.
The component knows nothing about HTML or the DOM, which is the way we like it.

### Keep template expressions simple
### Keep template statements simple
We bound `(blur)` to *two* JavaScript statements.

We like the first one, which calls `addHero`.
Expand All @@ -209,7 +209,7 @@ figure.image-display
input box (our design choice).

Although the example *works*, we are rightly wary of JavaScript in HTML.
Template expressions are powerful. We're supposed to use them responsibly.
Template statements are powerful. We're supposed to use them responsibly.
Complex JavaScript in HTML is irresponsible.

Should we reconsider our reluctance to pass the input box into the component?
Expand Down