diff --git a/docs/cookbook/cb-02-inline-styles tip.md b/docs/cookbook/cb-02-inline-styles tip.md index a4a30169ba..39d6f72ddd 100644 --- a/docs/cookbook/cb-02-inline-styles tip.md +++ b/docs/cookbook/cb-02-inline-styles tip.md @@ -19,4 +19,4 @@ var divStyle = { React.renderComponent(
Hello World!
, mountNode); ``` -Style keys are camelCased in order to be consistent with accessing the properties using node.style.___ in DOM. This also explains why WebkitTransition has an uppercase 'W'. +Style keys are camelCased in order to be consistent with accessing the properties using node.style.___ in DOM. This also explains why WebkitTransition has an uppercase "W". diff --git a/docs/cookbook/cb-02-inline-styles.md b/docs/cookbook/cb-02-inline-styles.md index 388620ec45..4dd44d05cb 100644 --- a/docs/cookbook/cb-02-inline-styles.md +++ b/docs/cookbook/cb-02-inline-styles.md @@ -24,4 +24,4 @@ React.renderComponent(
Hello World!
, mountNode); ``` ### Discussion -Style keys are camelCased in order to be consistent with accessing the properties using `node.style.___` in DOM. This also explains why `WebkitTransition` has an uppercase 'W'. +Style keys are camelCased in order to be consistent with accessing the properties using `node.style.___` in DOM. This also explains why `WebkitTransition` has an uppercase "W". diff --git a/docs/cookbook/cb-05-jsx-root-node-count tip.md b/docs/cookbook/cb-05-jsx-root-node-count tip.md index 86a49a108a..44e351d414 100644 --- a/docs/cookbook/cb-05-jsx-root-node-count tip.md +++ b/docs/cookbook/cb-05-jsx-root-node-count tip.md @@ -5,6 +5,6 @@ layout: docs permalink: jsx-root-node-count-tip.html --- -Currently in `render`, you can only return one node; if you have, say, a list of divs to return, you must wrap your components within, say, one big `div` or `span` (or any other component). +Currently in `render`, you can only return one node; if you have, say, a list of `div`s to return, you must wrap your components within, say, one big `div` or `span` (or any other component). Don't forget that JSX compiles into regular js, and returning two functions doesn't really make syntactic sense. diff --git a/docs/cookbook/cb-08-controlled-input-null-value tip.md b/docs/cookbook/cb-08-controlled-input-null-value tip.md index 2febcaf76c..83b252b1a5 100644 --- a/docs/cookbook/cb-08-controlled-input-null-value tip.md +++ b/docs/cookbook/cb-08-controlled-input-null-value tip.md @@ -7,7 +7,7 @@ permalink: controlled-input-null-value-tip.html With a controlled input component, specifying a `value` prevents the user from changing the input unless you desire so (more info [here](forms.html)). -You might have ran into a problem where you specified a `value` but the input can still be changed. In this case, you might have accidentally set your `value` to `undefined` or `null`. The snippet below shows this phenomenon; after a second, the text can be edited. +You might have run into a problem where you specified a `value` but the input can still be changed. In this case, you might have accidentally set your `value` to `undefined` or `null`. The snippet below shows this phenomenon; after a second, the text can be edited. ```js /** @jsx React.DOM */ diff --git a/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting-tip.md b/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting-tip.md index d40fc0df1a..283cd6fbe0 100644 --- a/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting-tip.md +++ b/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting-tip.md @@ -5,6 +5,6 @@ layout: docs permalink: componentWillReceiveProps-not-triggered-after-mounting-tip.html --- -`componentWillReceiveProps` isn't triggered after the node is put on scene. This is by design. Checkout [other lifecycle methods](component-specs.html) for the one that suits your needs. +`componentWillReceiveProps` isn't triggered after the node is put on scene. This is by design. Check out [other lifecycle methods](component-specs.html) for the one that suits your needs. The reason for that is because `componentWillReceiveProps` often handles the logic of comparing with the old props and act upon changes; not triggering it at mounting, where there are no old props, clearly defines what the method should do. diff --git a/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting.md b/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting.md index 1b42a38d16..c9254504af 100644 --- a/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting.md +++ b/docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting.md @@ -9,7 +9,7 @@ permalink: componentWillReceiveProps-not-triggered-after-mounting.html `componentWillReceiveProps` isn't triggered after the node is put on scene. ### Solution -This is by design. Checkout [other lifecycle methods](component-specs.html) for the one that suits your needs. +This is by design. Check out [other lifecycle methods](component-specs.html) for the one that suits your needs. ### Discussion `componentWillReceiveProps` often handles the logic of comparing with the old props and act upon changes; not triggering it at mounting, where there are no old props, clearly defines what the method should do.