{"componentChunkName":"component---src-templates-blog-post-js","path":"/blog/2020-07-11","result":{"data":{"markdownRemark":{"html":"

Optimization is fun because it's not necessary. - Brad Fitzpatrick

\n

While I don't necessarily agree with this statement in a strict sense, I do understand the point that Fitzpatrick is trying to make. Over optimization is a trap that the programmer needs to\nconstantly be on the lookout for, but that doesn't mean that we shouldn't make informed decisions upfront about architecture, standards, and strategies to make our apps as performant as possible.\nPutting in a timeboxed spike upfront can be an effective way to avoid pitfalls and \"gotchas\" when approaching a new feature or project, as it allows us to get a lay of the land and and forces\nus to look at exactly what we're trying to accomplish. This way we establish a scope and then we can always iterate and optimize as we get further into development.

\n

When it comes to React, there\naren't many things we need to worry about upfront, in terms of performance. The use of the virtual DOM means that even the most inefficient React app still tends to be relatively performant. But the\none area where React doesn't take any chances is the component render lifecycle. Our friends at Facebook want to make sure that our UIs are always up to date, even if it means that we waste render cycles\nthat are redundant or unnecessary. Luckily, React gives us several ways to help prune down unnecessary calls to a component's render method. Typically, this is done using the shouldComponentUpdate method,\nbut if we know that we never want to re-render a component unless the props or state changes then we can use Pure Components.

\n

A Little Bit of Context

\n

Before getting started, let's understand what happens when our components get updated. The component lifecycle has two phases: render and commit. The render phase is when the render method on the\ncomponent is called and the output is compared with the last copy on the virtual DOM (this process is called Reconciliation). The commit phase is when React updates the DOM with the determined changes and then invokes the lifecycle handler,\nlike componentDidUpdate. If we look at the React docs, we see that this render cycle gets kicked off anytime one of the following happens:

\n
    \n
  1. “state” values are updated
    2. \n
  2. “props” values are updated
    3. \n
  3. this.forceUpdate() is called
    4. \n
\n

Now, there is an additional case that is often overlooked. When React decides that a component needs to be updated, that means that it plans to re-render the entire subtree of that component. This\nmeans that all the child components will be re-rendered, along with the parent. So, let's update our list to make this clear:

\n
    \n
  1. “state” values are updated
    2. \n
  2. “props” values are updated
    3. \n
  3. this.forceUpdate() is called
    4. \n
  4. any of the above happen in a parent component
    5. \n
\n

To be as explicit as possible, let's walk through exactly what happens when one of these cases is true.

\n

\n \n \n \n \n

\n

As shown in the diagram, we can use shouldComponentUpdate (or the equivalent when using Hooks in functional components) to bypass the render lifecycle altogether. This means that we avoid all the overhead\nof the diffing algorithm used during the reconciliation. It is a smarter and more efficient way for us to directly tell React \"no need to bother figuring out if this component needs re-rendered - it doesn't.\"\nBut the React developers figured out that in many cases, we never want to re-render our component if the props haven't changed - the output is always driven entirely by the inputs, hence the name \"pure\" components. We could write shouldComponentUpdate methods that compare all the props\nfor each of our components, but that sounds like a lot of work. If only there was a standard way to encapsulate that behavior for all of our simpler components...

\n

Pure Components

\n

PureComponents do not re-render when the props and/or state have been updated with the same values. They provide the same interface as a standard Component, except that the shouldComponentUpdate method\nis implemented for us with a shallow comparison of the state and props. Note that this is a shallow comparison, meaning that non-primitives will be compared by reference. There are ways to handle this that\nmay be covered in a future post. A PureComponent can be implemented as follows:

\n
import React, { PureComponent } from \"react\";\n\nclass Pure extends PureComponent {\n  render() {\n    return <div />;\n  }\n}\n\nexport default Pure;\n
\n

Simple enough. But what about functional components? Not to fear, React gives us an HOC called memo that we can use to make our functional components pure using memoization.\nA pure functional component might look something like:

\n
import React, { memo } from \"react\";\n\nconst Pure = () => {\n  return <div />;\n};\n\nexport default memo(Pure);\n
\n

Let's look at some concrete examples to tie this off. Suppose we have an app with a simple Counter component that takes a prop count and displays the count in a <p> tag. A bit contrived, but it'll do.\nNow, let's say that the count prop is driven by the state of a parent App component, and the count is incremented each time we press a button.

\n

Our App would look like:

\n
import React, { useState } from \"react\";\nimport \"./App.css\";\n\nimport Counter from \"./Counter\";\n\nfunction App() {\n  const [count, setCount] = useState(0);\n  return (\n    <div className=\"App\">\n      <Counter count={count} />\n      <button onClick={() => setCount(count + 1)}>Increment</button>\n    </div>\n  );\n}\n\nexport default App;\n
\n

And our Counter would look like:

\n
import React from \"react\";\n\nconst Counter = ({ count }) => {\n  return <p>{count}</p>;\n};\n\nexport default Counter;\n
\n

We can use the Profiler React Dev Tool to analyze the render lifecycle when we increment the count.

\n

\n \n count prop being passed in to always be 0.

\n
import React, { useState } from \"react\";\nimport \"./App.css\";\n\nimport Counter from \"./Counter\";\n\nfunction App() {\n  const [count, setCount] = useState(0);\n  return (\n    <div className=\"App\">\n      <Counter count={0} />\n      <button onClick={() => setCount(count + 1)}>Increment</button>\n    </div>\n  );\n}\n\nexport default App;\n
\n

In this new contrived example, we never need our Counter component to re-render, even when the parent's state changes and a re-render is triggered for the parent. But when we look at the Profiler in this\ncase, we see something unexpected.

\n

\n \n \n \n \n

\n

It looks like the child Counter component re-rendered even though we didn't need it to. Again, this is because the entire component subtree is re-rendered by default anytime an update is triggered for\na component. But we can solve this with pure components.

\n

Now, let's say we have a PureCounter component that uses React Memo.

\n
import React, { memo } from \"react\";\n\nconst PureCounter = ({ count }) => {\n  return <p>{count}</p>;\n};\n\nexport default memo(PureCounter);\n
\n

And we implement that component in the main App.

\n
import React, { useState } from \"react\";\nimport \"./App.css\";\n\nimport PureCounter from \"./PureCounter\";\n\nfunction App() {\n  const [count, setCount] = useState(0);\n  return (\n    <div className=\"App\">\n      <PureCounter count={count} />\n      <button onClick={() => setCount(count + 1)}>Increment</button>\n    </div>\n  );\n}\n\nexport default App;\n
\n

If we look at the standard example using PureCounter in the Profiler, it looks exactly the same as the normal Counter. This is because in both cases the components actually need re-rendered when the count changes.

\n

\n \n \n \n \n

\n

But now let's look what happens when we set the count prop to always be 0 like we did for the second example with the normal Counter.

\n
import React, { useState } from \"react\";\nimport \"./App.css\";\n\nimport PureCounter from \"./PureCounter\";\n\nfunction App() {\n  const [count, setCount] = useState(0);\n  return (\n    <div className=\"App\">\n      <PureCounter count={0} />\n      <button onClick={() => setCount(count + 1)}>Increment</button>\n    </div>\n  );\n}\n\nexport default App;\n
\n

And when we look at the Profiler.

\n

\n \n \n \n \n

\n

Look at that! Our PureCounter component didn't re-render, like we wanted. This, again, is because memo is automatically determining that the component does not need to be re-rendered due to the\nfact that the count prop didn't change.

\n

You can imagine how many redundant renders are being done in your component tree if you're not handling these cases. The larger the components, the more apparent it will be. So, do yourself a favor and just\nuse PureComponent or memo for your components that could be pure.

\n

Some Caveats

\n

As always, the usage depends on the case. Before using a pure component, make sure to ask yourself the following questions:

\n\n

If the answer to any of these questions is \"yes\" then you may need to reconsider using pure components in this case. If not, you should be free to proceed and take back those extra render cycles. Enjoy.

","frontmatter":{"date":"July 11, 2020","slug":"/blog/2020-07-11","title":"Optimizing your React component lifecycle using Pure Components"}}},"pageContext":{"slug":"/blog/2020-07-11"}}}