| The house attribute triggers the creation of House directive.
+
| The house attribute triggers the creation of the House directive.
| This is equivalent to:
| new House(injector.get(MyService));
```
@@ -264,13 +264,13 @@ Injecting other directives into directives follows a similar mechanism as inject
There are five kinds of visibilities:
-* (no annotation): Inject a directives only if it is on the curent element.
+* (no annotation): Inject a directives only if it is on the current element.
* `@ancestor`: Inject a directive if it is at any element above the current element.
* `@parent`: Inject a directive which is direct parent of the current element.
* `@child`: Inject a list of direct children which match a given type. (Used with `Query`)
* `@descendant`: Inject a list of any children which match a given type. (Used with `Query`)
-NOTE: if the injection constraint can not be satisfied by the current visibility constraint, than it is forward to normal injector which may provide a default value for the directive or it may throw an error.
+NOTE: if the injection constraint can not be satisfied by the current visibility constraint, then it is forward to the normal injector which may provide a default value for the directive or it may throw an error.
Here is an example of the kinds of injections which can be achieved:
@@ -330,7 +330,7 @@ Assume the following DOM structure for `my_app.html`:
### Shadow DOM effects on Dependency Injection
-Shadow DOM provides encapsulation for components, so as a general rule it does not allow directive injections to cross the shadow DOM boundries.
+Shadow DOM provides an encapsulation for components, so as a general rule it does not allow directive injections to cross the shadow DOM boundaries.
diff --git a/modules/angular2/docs/core/03_formatters.md b/modules/angular2/docs/core/03_formatters.md
index 6081749c92..8d68764579 100644
--- a/modules/angular2/docs/core/03_formatters.md
+++ b/modules/angular2/docs/core/03_formatters.md
@@ -1,7 +1,7 @@
# Formatters
Formatters can be appended on the end of the expressions to translated the value to a different format. Typically used
-to controll the stringification of numbers, dates, and other data, but can also be used for ordering, maping, and
+to control the stringification of numbers, dates, and other data, but can also be used for ordering, mapping, and
reducing arrays. Formatters can be chained.
NOTE: Formatters are known as filters in Angular v1.
diff --git a/modules/angular2/docs/core/10_view.md b/modules/angular2/docs/core/10_view.md
index 855d40fa0e..efa264f09a 100644
--- a/modules/angular2/docs/core/10_view.md
+++ b/modules/angular2/docs/core/10_view.md
@@ -51,7 +51,7 @@ And assume following HTML Template:
```
-The above template is compiled by the Compiler to create a ProtoView. The ProtoView is than used to
+The above template is compiled by the Compiler to create a ProtoView. The ProtoView is then used to
create an instance of the View. The instantiation process involves cloning the above template and
locating all of the elements which contain bindings and finally instantiating the Directives
associated with the template. (See compilation for more details.)
@@ -81,7 +81,7 @@ Note:
* View knows which expressions need to be watched.
* View knows what needs to be updated if the watched expression changes.
* All DOM elements are owned by single instance of the view.
-* The structure of the DOM can not change during runtime. To Allow structural changes to DOM we need
+* The structure of the DOM can not change during runtime. To allow structural changes to the DOM we need
to understand Composed View.
@@ -107,27 +107,27 @@ During the compilation process the Compiler breaks the HTML template into these
and
```
- | viewA(greeter)
@@ -205,7 +205,7 @@ And assume following HTML Template:
| viewA(greeter)
```
-The above UI is built using a single View, and hence single context `greeter`. It can be expressed
+The above UI is built using a single View, and hence a single context `greeter`. It can be expressed
in this pseudo-code.
```
@@ -215,7 +215,7 @@ var greeter = new Greeter();
The View contains two bindings:
1. `greeting`: This is bound to the `greeting` property on the `Greeter` instance.
-2. `name.value`: This poses a problem. There is no `name` property on `Greeter` instance. To solve
+2. `name.value`: This poses a problem. There is no `name` property on the `Greeter` instance. To solve
this we wrap the `Greeter` instance in the `Local` instance like so:
```
var greeter = new Locals(new Greeter(), {name: ref_to_input_element })
@@ -224,7 +224,7 @@ var greeter = new Locals(new Greeter(), {name: ref_to_input_element })
By wrapping the `Greeter` instance into the `Locals` we allow the view to introduce variables which
are in addition to the `Greeter` instance. During the resolution of the expressions we first check
-the locals, and then `Greeter` instance.
+the locals, and then the `Greeter` instance.