docs: follow/side effects/taught typos
This commit is contained in:
parent
814f3d01ef
commit
a120d7f1c8
|
@ -21,7 +21,7 @@ about the template runtime characteristics.
|
|||
## Summary
|
||||
|
||||
Below is a summary of the kinds of syntaxes which Angular templating supports. The syntaxes are explained in more
|
||||
detail in fallowing sections.
|
||||
detail in following sections.
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
|
@ -408,7 +408,7 @@ which allows us to further shorten the text.
|
|||
</ul>
|
||||
```
|
||||
|
||||
We can also optionaly use `var` instead of `#` and add `:` to `ng-repeat` which creates the fallowing recomended
|
||||
We can also optionaly use `var` instead of `#` and add `:` to `ng-repeat` which creates the following recomended
|
||||
microsyntax for `ng-repeat`.
|
||||
|
||||
```
|
||||
|
@ -418,7 +418,7 @@ microsyntax for `ng-repeat`.
|
|||
```
|
||||
|
||||
The format is intentionally defined freely, so that developers of directives can build expressive microsyntax for
|
||||
their directives. Fallowing describes a more formal definition.
|
||||
their directives. Following describes a more formal definition.
|
||||
|
||||
```
|
||||
expression: ... // as defined in Expressions section
|
||||
|
@ -518,7 +518,7 @@ have different semantics.
|
|||
### Expressions
|
||||
|
||||
Expressions can be used to bind to a properties only. Expressions represent how data should be projected to the View.
|
||||
Expressions should not have any sideeffects and should be idempotent. Examples of where expressions can be used in
|
||||
Expressions should not have any side effects and should be idempotent. Examples of where expressions can be used in
|
||||
Angular are:
|
||||
```
|
||||
<div title="{{expression}}">{{expression}}</div>
|
||||
|
@ -537,7 +537,7 @@ langugage, binding expressions behave differently in following ways:
|
|||
This is done to allow early detection of errors in the templates.
|
||||
* *Safe dereference*: Expressions `user.name` where `user` is null will throw `NullPointerException` in the langugage.
|
||||
In contrast Angular will silently ignore `null` on `user`. This is done because Views often have to wait for the data
|
||||
to arrive from the backend and many fields will be null until the data arrives. Safe dereference so cammon in the
|
||||
to arrive from the backend and many fields will be `null` until the data arrives. Safe dereference is so common in the
|
||||
Views, that we have made it the default.
|
||||
* *Single expression*: An expression must be a single statemnet. (i.e. no `;`)
|
||||
* *No assignments*: Binding expressions can not contain assignments.
|
||||
|
@ -573,15 +573,15 @@ Examples of where statments can be used in Angular are:
|
|||
```
|
||||
|
||||
Statements are similar to statments in the langugage in which you are writing your application. (i.e.
|
||||
statments fallow JS syntax and semantics in JS and Dart syntax and semantics in Dart). Unlike statments in the
|
||||
statments follow JS syntax and semantics in JS and Dart syntax and semantics in Dart). Unlike statments in the
|
||||
langugage, binding expressions behave differently in following ways:
|
||||
|
||||
* *Unsafe dereference*: Expressions `user.verify()` where `user` is null will throw `NullPointerException` in the
|
||||
* *Unsafe dereference*: Expressions `user.verify()` where `user` is `null` will throw `NullPointerException` in the
|
||||
langugage as well as in statments. (In contrast to Safe dereference in Angular expressions.) While angular protects
|
||||
you from null dereferencing in expressions due to lazy loading of data, no such protection is required for statments,
|
||||
and doing so would make it harder to detect typos in statements.
|
||||
* *Multiple statements OK*: Statements can be composed from more than one statemnet. (i.e. no `doA(); doB()`)
|
||||
* *Assignments OK*: Event bindings can have sideeffects and hence assignments are allowed.
|
||||
* *Assignments OK*: Event bindings can have side effects and hence assignments are allowed.
|
||||
* *No keywords*: Statements can not contain keywords such as: `var`, `if`, and so on.
|
||||
* *No Formatters*: Angular statements can not contain formatters. (Formatters are only usefull for data binding)
|
||||
|
||||
|
|
|
@ -88,7 +88,7 @@ Example of usage:
|
|||
|
||||
```<span tooltip="Tooltip text goes here.">Some text here.</span>```
|
||||
|
||||
The developer of an applacation can now freely use the `tooltip` attribute wherever the behavior is needed. The code above has tought the browser a new reusable and declarative bahavior.
|
||||
The developer of an applacation can now freely use the `tooltip` attribute wherever the behavior is needed. The code above has taught the browser a new reusable and declarative bahavior.
|
||||
|
||||
Notice that databinding will work with this decorator with no further effort as show below.
|
||||
|
||||
|
@ -214,7 +214,7 @@ Dependency Injection (DI) is a key aspect of directives. DI allows directives to
|
|||
|
||||
When Angular directives are instantiated, the directive can ask for other related directives to be injected into it. By assembing the directives in different order and subtypes the application behavior can be controlled. A good mental model is that DOM structure controlles the directive instantiation graph.
|
||||
|
||||
Directive instantiation is triggered by the directive CSS selector matching the DOM structure. The directive in its constructor can ask for other directives or application services. When asking for directives the dependency is locating by fallowing the DOM hieranchy and if not found using the application level injector.
|
||||
Directive instantiation is triggered by the directive CSS selector matching the DOM structure. The directive in its constructor can ask for other directives or application services. When asking for directives the dependency is locating by following the DOM hieranchy and if not found using the application level injector.
|
||||
|
||||
To better understand the kinds of injections which are supported in Angular we have broken them down into use case examples.
|
||||
|
||||
|
@ -251,7 +251,7 @@ class House { |
|
|||
|
||||
```
|
||||
|
||||
Assume fallowing DOM structure for `my_app.html`:
|
||||
Assume the following DOM structure for `my_app.html`:
|
||||
```
|
||||
<div house> | The house attribute triggers the creation of House directive.
|
||||
</div> | This is equivalent to:
|
||||
|
@ -261,7 +261,7 @@ Assume fallowing DOM structure for `my_app.html`:
|
|||
|
||||
### Injecting other Directives
|
||||
|
||||
Injecting other directives into directives fallows similar mechanism as injecting services, but with added constraint of visibility governed by DOM structure.
|
||||
Injecting other directives into directives follows a similar mechanism as injecting services, but with added constraint of visibility governed by DOM structure.
|
||||
|
||||
There are five kinds of visibilities:
|
||||
|
||||
|
@ -316,7 +316,7 @@ class Primary { |
|
|||
} |
|
||||
```
|
||||
|
||||
Assume fallowing DOM structure for `my_app.html`:
|
||||
Assume the following DOM structure for `my_app.html`:
|
||||
```
|
||||
<form> |
|
||||
<div> |
|
||||
|
|
Loading…
Reference in New Issue