More edits

content/blog/2018-05-23-react-v-16-4.md

@@ -1,9 +1,9 @@
 ---
-title: "React v16.4.0: Support for Pointer Events"
+title: "React v16.4.0: Pointer Events"
 author: [acdlite]
 ---
 
-React 16.4 adds an oft-requested feature: pointer events!
+The latest minor release adds support for an oft-requested feature: pointer events!
 
 It also includes a bugfix for `getDerivedStateFromProps`. Check out the full [changelog](#changelog) below.
 
@@ -22,31 +22,35 @@ The following event types are now available in React DOM:
 - `onPointerOver`
 - `onPointerOut`
 
-Please note that these events will only work in browsers that support the Pointer Events specification. (At the time of this writing, this includes the latest versions of Chrome, Firefox, Edge, and Internet Explorer.) If your application depends on pointer events, we recommend using a third-party pointer events polyfill; we have opted not to include such a polyfill in React DOM, since it would bloat the bundle size.
+Please note that these events will only work in browsers that support the Pointer Events specification. (At the time of this writing, this includes the latest versions of Chrome, Firefox, Edge, and Internet Explorer.) If your application depends on pointer events, we recommend using a third-party pointer events polyfill. We have opted not to include such a polyfill in React DOM, to avoid an increase in bundle size.
 
 Huge thanks to [Philip Spiess](https://github.com/philipp-spiess) for contributing this change!
 
 ## Bugfix for `getDerivedStateFromProps`
 
-`getDerivedStateFromProps` is now called every time a component is rendered, regardless of the cause of the update. Previously, it was only called if the component was re-rendered by its parent; it would not fire as the result of a local `setState`. This was an oversight in the initial implementation that has now been corrected. The previous behavior was more similar to how `componentWillReceiveProps` works, but the improved behavior ensures compatibility with React's upcoming asynchronous rendering mode.
+`getDerivedStateFromProps` is now called every time a component is rendered, regardless of the cause of the update. Previously, it was only called if the component was re-rendered by its parent, and would not fire as the result of a local `setState`. This was an oversight in the initial implementation that has now been corrected. The previous behavior was more similar to `componentWillReceiveProps`, but the improved behavior ensures compatibility with React's upcoming asynchronous rendering mode.
 
-**Most likely, this doesn't require any changes to your components**. The rare cases where it does matter fall into one of two categories:
+**Most likely, this doesn't require any changes to your components**.  The rare cases where it does matter fall into one of two categories.
 
-### Avoid Side Effects in `getDerivedStateFromProps`
+### 1. Avoid Side Effects in `getDerivedStateFromProps`
 
-Like the render method, `getDerivedStateFromProps` should be a pure function of props and state. You should move side-effectful code elsewhere. E.g. Flux dispatches typically belong inside the originating event handler; DOM mutations belong inside `componentDidMount` or `componentDidUpdate`.
+Like the render method, `getDerivedStateFromProps` should be a pure function of props and state. You should move side-effectful code elsewhere. E.g. Flux dispatches typically belong inside the originating event handler. DOM mutations belong inside `componentDidMount` or `componentDidUpdate`.
 
 Side effects in `getDerivedStateFromProps` were already disallowed, but since it now fires more often than it used to, the recent change may expose previously undiscovered bugs.
 
-### Compare Incoming Props to Previous Props When Computing Controlled Values
+You can read more about this in our recent post about [preparing for asynchronous rendering](/blog/2018/03/27/update-on-async-rendering.html).
 
-The following code assumes `getDerivedStateFromProps` only fires on prop changes. But since it now fires for state changes, too, local updates to the controlled value will be ignored, since the props version always overrides it.
+### 2. Compare Incoming Props to Previous Props When Computing Controlled Values
+
+The following code assumes `getDerivedStateFromProps` only fires on prop changes:
 
 ```js
 static getDerivedStateFromProps(props, state) {
   if (props.value !== state.controlledValue) {
     return {
-      // Props always win. Oops!
+      // Since this method fires on both props and state changes, local updates
+      // to the controlled value will be ignored, since the props version always
+      // overrides it.
       controlledValue: props.value,
     };
   }
@@ -54,12 +58,12 @@ static getDerivedStateFromProps(props, state) {
 }
 ```
 
-You can change it to do this instead:
+One possible way to fix this is to compare the incoming value to the previous value by storing the previous props in state:
 
 ```js
 static getDerivedStateFromProps(props, state) {
   const prevProps = state.prevProps;
-  // Compare incoming props to previous props
+  // Compare the incoming prop to previous prop
   const controlledValue =
     prevProps.value !== props.value
       ? props.value
@@ -72,6 +76,10 @@ static getDerivedStateFromProps(props, state) {
 }
 ```
 
+However, try to avoid mixing props and state in this way. Prefer to have one source of truth for any value, and [lift state up](/docs/lifting-state-up.html) if necessary to share it between multiple components.
+
+Please remember that **most components do not need `getDerivedStateFromProps`**. It's not meant to serve as a one-to-one replacement for `componentWillReceiveProps`. We'll publish a follow-up post in the coming weeks with more recommendations on how to use (and not use) `getDerivedStateFromProps`.
+
 ## Installation
 
 React v16.4.0 is available on the npm registry.