Document how highlight updates works in the optimizing performance pa… (#387)
* Document how highlight updates works in the optimizing performance page - closes#360
* Change example animated gif to not mention Redux
* Be more explicit about the theory and workflow around using Highlight Updates - closes#360
* improve grammar, correctly label link to #avoid-reconciliation
* Trim content to its essentials and move to a more relevant place in Avoid Reconciliation section - Closes#360
* Make requested changes to wording and host images internally
* Minor rewording
@ -192,7 +192,25 @@ React builds and maintains an internal representation of the rendered UI. It inc
When a component's props or state change, React decides whether an actual DOM update is necessary by comparing the newly returned element with the previously rendered one. When they are not equal, React will update the DOM.
In some cases, your component can speed all of this up by overriding the lifecycle function `shouldComponentUpdate`, which is triggered before the re-rendering process starts. The default implementation of this function returns `true`, leaving React to perform the update:
You can now visualize these re-renders of the virtual DOM with React DevTools:
In the developer console select the **Highlight Updates** option in the **React** tab:
<center><imgsrc="../images/blog/devtools-highlight-updates.png"style="max-width:100%; margin-top:10px;"alt="How to enable highlight updates"/></center>
Interact with your page and you should see colored borders momentarily appear around any components that have re-rendered. This lets you spot re-renders that were not necessary. You can learn more about this React DevTools feature from this [blog post](https://blog.logrocket.com/make-react-fast-again-part-3-highlighting-component-updates-6119e45e6833) from [Ben Edelstein](https://blog.logrocket.com/@edelstein).
Note that when we're entering a second todo, the first todo also flashes on the screen on every keystroke. This means it is being re-rendered by React together with the input. This is sometimes called a "wasted" render. We know it is unnecessary because the first todo content has not changed, but React doesn't know this.
Even though React only updates the changed DOM nodes, re-rendering still takes some time. In many cases it's not a problem, but if the slowdown is noticeable, you can speed all of this up by overriding the lifecycle function `shouldComponentUpdate`, which is triggered before the re-rendering process starts. The default implementation of this function returns `true`, leaving React to perform the update:
If you know that in some situations your component doesn't need to update, you can return `false` from `shouldComponentUpdate` instead, to skip the whole rendering process, including calling `render()` on this component and below.
In most cases, instead of writing `shouldComponentUpdate()` by hand, you can inherit from [`React.PureComponent`](/docs/react-api.html#reactpurecomponent). It is equivalent to implementing `shouldComponentUpdate()` with a shallow comparison of current and previous props and state.
## shouldComponentUpdate In Action
Here's a subtree of components. For each one, `SCU` indicates what `shouldComponentUpdate` returned, and `vDOMEq` indicates whether the rendered React elements were equivalent. Finally, the circle's color indicates whether the component had to be reconciled or not.