Sync with reactjs.org @ e3cf542e

content/blog/2018-06-07-you-probably-dont-need-derived-state.md

@@ -213,7 +213,7 @@ To recap, when designing a component, it is important to decide whether its data
 Instead of trying to **"mirror" a prop value in state**, make the component **controlled**, and consolidate the two diverging values in the state of some parent component. For example, rather than a child accepting a "committed" `props.value` and tracking a "draft" `state.value`, have the parent manage both `state.draftValue` and `state.committedValue` and control the child's value directly. This makes the data flow more explicit and predictable.
 
 For **uncontrolled** components, if you're trying to reset state when a particular prop (usually an ID) changes, you have a few options:
-* **Recomendation: To reset _all internal state_, use the `key` attribute.**
+* **Recommendation: To reset _all internal state_, use the `key` attribute.**
 * Alternative 1: To reset _only certain state fields_, watch for changes in a special property (e.g. `props.userID`).
 * Alternative 2: You can also consider fall back to an imperative instance method using refs.
 

content/docs/hooks-reference.md

@@ -232,7 +232,7 @@ You can also create the initial state lazily. To do this, you can pass an `init`
 
 It lets you extract the logic for calculating the initial state outside the reducer. This is also handy for resetting the state later in response to an action:
 
-```js{1-3,11-12,21,26}
+```js{1-3,11-12,19,24}
 function init(initialCount) {
   return {count: initialCount};
 }
@@ -246,9 +246,7 @@ function reducer(state, action) {
     case 'reset':
       return init(action.payload);
     default:
-      // A reducer must always return a valid state.
-      // Alternatively you can throw an error if an invalid action is dispatched.
-      return state;
+      throw new Error();
   }
 }