Merge pull request #35 from trentmwillis/guide-fixes

Fix typos and clarify guides

Author: chadhietala

guides/rules/no-attrs-snapshot.md

@@ -1,6 +1,6 @@
 # No `attrs` snapshots
 
-In 2.0.0 [`didRecieveAttrs`](https://guides.emberjs.com/v2.9.0/components/the-component-lifecycle/#toc_formatting-component-attributes-with-code-didreceiveattrs-code) and [`didUpdateAttrs`](https://guides.emberjs.com/v2.9.0/components/the-component-lifecycle/#toc_resetting-presentation-state-on-attribute-change-with-code-didupdateattrs-code) hooks were introduced are called whenever the arguments to a component referencially change. These hooks do recieve params to them, however one should not use them as they force those objects to reify which can be very costly when you have a lot of components on the page. These arguments are also purposly undocumented. If for some reason you need to do a comparison of arguments we suggest that you simply keep a cache on the component.
+In 2.0.0, [`didRecieveAttrs`](https://guides.emberjs.com/v2.9.0/components/the-component-lifecycle/#toc_formatting-component-attributes-with-code-didreceiveattrs-code) and [`didUpdateAttrs`](https://guides.emberjs.com/v2.9.0/components/the-component-lifecycle/#toc_resetting-presentation-state-on-attribute-change-with-code-didupdateattrs-code) hooks were introduced. These hooks are called whenever the arguments to a component referentially change. These hooks recieve params, however one should not use them as they force those objects to reify which can be very costly when you have a lot of components on the page. These arguments are also purposely undocumented. If for some reason you need to do a comparison of arguments we suggest that you simply keep a cache on the component.
 
 ```
 export default Ember.Component({

guides/rules/no-attrs.md

@@ -2,6 +2,6 @@
 
 **TL;DR** Use `_` to prefix things that are local and leave passed items as the bare name.
 
-In the runup to Ember 2.0, several blog articles were written about using `this.attrs` but they have never been documented as a public API. Typically people use attrs to denote things as "passed" and bare names as local. This is useful and some iteration of Ember will have this built into the programming model, but for now we should not use `attrs`.
+In the runup to Ember 2.0, several blog articles were written about using `this.attrs` but this feature has never been documented as a public API. Typically people use `attrs` to denote properties and methods as having been "passed" in to a component and bare names as properties local to the component. This is useful and some iteration of Ember will have this built into the programming model, but for now we should not use `attrs`.
 
-In JavaScript we typically prefix "private" things in JavaScript with `_`. If you want to create this notion in a component, we can leverage this long standing convention. Things that are local are technically private as component's scope is isolated so marking them with `_` semantically makes sense. Passed items can use the bare name, as they are effectively public/protected methods and properties.
+In JavaScript we typically prefix "private" things with `_`. If you want to create this notion in a component, we can leverage this long standing convention. Things that are local are technically private as a component's scope is isolated so marking them with `_` makes sense semantically. Passed items can use the bare name, as they are effectively public/protected methods and properties.

guides/rules/no-lifecycle-events.md

@@ -1,11 +1,11 @@
 # No Lifecycle Events
 
-Ember tracks changes and notifies listeners of those changes. This is quite powerful, and prevents “glue” code to propagate changes. This also enables granular updates, rather than whole-world rebuild scenarios. This comes at a downside, we can easily accidentally (today) trigger these “update” code-paths, when they are not required. This comes largely at a performance cost. For example, if during initial render we are actually also re-rendering. This is wasteful. Ember keeps getting better at detecting these cases and informing the developer. Unfortunately it is not perfect yet. When we use the lifecycle events we are incuring double work as we must event and also call the method hooks on the object. Because of this we should simply do the work in a [lifecycle hook](https://guides.emberjs.com/v2.10.0/components/the-component-lifecycle/).
+Ember tracks changes and notifies listeners of those changes. This is quite powerful and prevents the need for “glue” code to propagate changes. This also enables granular updates, rather than whole-world rebuild scenarios. This comes at a downside, we can easily trigger these “update” code-paths on accident, when they are not required. This comes largely at a performance cost. For example, if during initial render we also cause a re-render, then this is wasteful. Ember keeps getting better at detecting these cases and informing the developer. Unfortunately it is not perfect yet. When we use the lifecycle events we are incuring double work as we must event and also call the method hooks on the object. Because of this we should simply do the work in a [lifecycle hook](https://guides.emberjs.com/v2.10.0/components/the-component-lifecycle/).
 
 ```
 // Good
 export default Ember.Component.extend({
-  init() { // good example
+  init() {
     this._super(...arguments);
     this.set('first', 'stefan');
     this.set('last', 'Penner');

guides/rules/no-observers.md

@@ -11,7 +11,7 @@ Observers suffer from several issues when building applications at scale. These
 To unroll what this means consider the example below.
 
 ```
-Compontent.extend({
+Component.extend({
   firstName: 'Chad',
   lastName: 'Hietala',
   fullName: undefined,
@@ -30,12 +30,12 @@ this.set('lastName', 'Penner');
 <---------------------------------------- Now `fullName` is Stefan Penner
 ```
 
-Sense observers eagerly compute we have this period in time where we have computed a `fullName` that is not what actually care about.  When we introduce many observers into an application this problem compounds on it's self.
+Since observers eagerly compute we have this period in time where we have computed a `fullName` that is not what we actually care about. When we introduce many observers into an application this problem compounds on itself.
 
-In contrast a computed property is lazily computed and memoized. This means that `firstName` and `lastName` can freely mutate and only when we do `this.get('fullName');` will the function body of the computed property will run. This gives us a clear caller in terms of why the body of why `fullName` was recomputed.
+In contrast a computed property is lazily computed and memoized. This means that `firstName` and `lastName` can freely mutate and only when we do `this.get('fullName');` will the function body of the computed property run. This gives us a clear caller in terms of why the body of `fullName` was recomputed.
 
 ```
-Compontent.extend({
+Component.extend({
   firstName: 'Chad',
   lastName: 'Hietala',
   fullName: computed('firstName', 'lastName', function() {

guides/rules/no-side-effect-cp.md

@@ -1,13 +1,13 @@
 # No Computed Property Side-effects
 
-In Ember we want data to flow down from the route and send actions up modifiy that data. This means that data flows from the top of the application tree structure and passes down to the child nodes. These children are not the owners of the data passed to them. Instead, they derive their own data based on the passed data. Those children can then choose to pass forward that derived data to its child and so on. If a child needs to mutate data passed to it, it must ask for it by firing any action. Once the owner makes the mutation, that change is propagated back down.
+In Ember we want data to flow down from the route and send actions up to modify that data. This means that data flows from the top of the application tree structure and passes down to the child nodes. These children are not the owners of the data passed to them. Instead, they derive their own data based on the passed data. Those children can then choose to pass forward that derived data to its child and so on. If a child needs to mutate data passed to it, it must ask for it by firing an action. Once the owner makes the mutation, that change is propagated back down.
 
 When we send actions in computed properties we are violating this pattern which makes systems much more difficult to reason about. Specifically with actions in computed propertites what we are semantically saying is:
 
 1. When I first access this property send an action
 2. This action will not fire again unless the dependent key of this computed property changes.
 
-The fact that property access could cause some side effect to occur is less than ideal as it forces you to write code that reacts to data changing over time instead of controlling the side effects based on user input into the system. Often when we see this pattern we see that one component is responsible displaying the data and another unrelated component is handles the action. This then forces a developer to look in mutliple places to understand how the component works. We can see this in the following example
+The fact that property access could cause some side effect to occur is less than ideal as it forces you to write code that reacts to data changing over time instead of controlling the side effects based on user input into the system. Often when we see this pattern we see that one component is responsible for displaying the data and another, unrelated component handles the action. This then forces a developer to look in mutliple places to understand how the component works. We can see this in the following example
 
 ```
 <input value={{firstName}} />
@@ -26,7 +26,7 @@ Ember.Component.extend({
 })
 ```
 
-As you can see above, when we do side-effect programing we are forced to remove concerns of one component into another. More specically, `isValid` and the `validateAction` are passed to the component to call whenever the component changes it's `firstName` property. We can't look at just this component to see how validation is performed on our input. In contrast we can localize this logic and directly turn browser events e.g. oninput into semantic event `validateNameLength`. Here we are directly controlling the side-effects by taking an event in and directly handleing it, as opposed to rebroadcasting based on `firstName` changing.
+As you can see above, when we do side-effect programing we are forced to move concerns of one component into another. More specifically, `isValid` and the `validateAction` are passed to the component to call whenever the component changes its `firstName` property. We can't look at just this component to see how validation is performed on our input. In contrast, we can localize this logic and directly turn browser events (e.g., oninput) into a semantic event, such as `validateNameLength`. Here we are directly controlling the side-effects by taking an event in and directly handling it, as opposed to rebroadcasting based on `firstName` changing.
 
 ```
 <input value={{firstName}} oninput={{action 'validateNameLength'}} />