fix typo in blog post

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.