{"data":{"site":{"siteMetadata":{"title":"This web dev stuff is hard","author":"Paul Armstrong"}},"markdownRemark":{"id":"8b13b802-6249-5d29-a7be-667836045d3b","excerpt":"Rendering large trees of components in React can be expensive. When the state managed by Redux changes, it triggers updates to the main component tree and on…","html":"

Rendering large trees of components in React can be expensive. When the state managed by Redux changes, it triggers updates to the main component tree and on down through all of the sub-trees. When state updates often, this can start to slow down your application while it needs to re-render every component.

\n

To prevent this from happening, you might make use of PureComponent and shouldComponentUpdate. While each of these is a strategy for managing updates to components and their sub-trees, there are certain patterns that can slip by and not be caught appropriately.

\n

It is also important to understand that using PureComponent is typically the goal, whenever possible, since it is optimized at React’s library level. Custom shouldComponentUpdate implementations are encouraged when PureComponent may not be possible (e.g. an entire data structure object is required as a prop to render a component, like a Tweet object).

\n
\n

Note: I found this in some archives of half-finished blog posts written sometime between 2015 and 2018. Some items may be a bit dated, the patterns not super new, but I hope that the lessons and ideas are helpful either way.

\n
\n

New Arrays and Objects

\n

Most components use (or should use) shallow comparisons against their props and state during shouldComponentUpdate (or in PureComponent) in order to determine whether or not they need to be updated and re-rendered.

\n

When a property is an object or array, every time a new instance of one is passed in, it will fail shallow comparison and trigger an update. Take the following scenarios:

\n

Static data

\n
  render() {\n    return (\n-     <Component locationState={{ foo: 'bar' }} />\n    );\n  }
\n

In the above case, every time render is called, a new object with the same key/value pairs will be sent in every time. This is unnecessary, since the data is static. It can easily be alleviated by hoisting the static data outside of any lifecycle.

\n
+ const locationState = { foo: 'bar' };\n\n// ...\n\n  render() {\n    return (\n+     <Component locationState={locationState} />\n    );\n  }
\n

Now, this.props.locationState will always be stricly equal (===) to nextProps.locationState and not trigger an update/re-render when using a PureComponent.

\n

Building from instance props or state

\n
  render() {\n-   const { item1, item2 } = this.props;\n    return (\n-     <Component data={[ item1, item2 ]} />\n    );\n  }
\n

In this case, a sub-component is dependent on the current component’s props and state. It may not be possible to prevent rendering at the parent level, so we need another solution to avoid creating a new array instance of these properties if they haven’t changed.

\n
+ import createInstanceSelector from 'modules/create-instance-selector';\n\n// ...\n\n  render() {\n    return (\n+     <Component data={this.getData()} />\n    );\n  }\n\n+ getData = createInstanceSelector(\n+   (props, state) => props.item1,\n+   (props, state) => props.item2,\n+   (item1, item2) => [ item1, item2 ]\n+ );
\n

We have a module called createInstanceSelector for this purpose. It works like reselect’s selectors, in that it memoizes composable, derived data. In the above case, this.getData() will only return a new array if either props.item1 or props.item2 has changed since the last call. Here’s an example of how you might implement that:

\n
import createSelector from 'reselect'\n\nexport default (componentInstance, ...selectors) => {\n  const instanceSelector = createSelector(...selectors)\n  return (instance = componentInstance) =>\n    instanceSelector(instance.props, instance.state, { ...instance })\n}
\n

New Functions

\n

Similar to arrays and objects, every time a function is defined, it will fail strict equality checks. There are multiple ways to ensure you don’t create a new function on each render cycle. Pick the one that works best for you.

\n
  render() {\n    return (\n-     <Component identityFunction={(item) => item.id} />\n    );\n  }
\n
+ const identityFunction = (item) => item.id;\n  // ...\n  render() {\n    return (\n+     <Component identityFunction={identityFunction} />\n    );\n  }
\n

Tip: You can use the eslint-plugin-react/jsx-no-bind rule to disallow the undesired pattern

\n

Components

\n
  render() {\n    return (\n-     <Component button={<Button />} />\n    )\n  }
\n

Functions that render sub-trees

\n
  class ParentComponent extends Component {\n    render() {\n      return (\n-       <Component renderButtons={this._renderButtons}\n      );\n    }\n\n-   _renderButtons = () => {\n-     const { items } = this.props;\n-     return items.map((item, i) => <Item data={item} key={i} />);\n-   };\n  }
\n

When to use this pattern

\n\n

When not to use this pattern

\n\n

Keep in mind, performance is almost always application specific. When you use PureComponent or shouldComponentUpdate are up to your needs. Take everything here as a starting guideline and not an end-all, be-all.

","frontmatter":{"title":"Prop type performance considerations for React","date":"January 03, 2019"}}},"pageContext":{"slug":"/02-prop-types/","previous":{"fields":{"slug":"/01-new-blog/"},"frontmatter":{"title":"A new blog"}},"next":null}}