tl;dr; Use React.PureComponent (or React.Component) if your component contains, or might contain, non-trivial logic that might affect it rendering or not. For all other cases, use a function, especially if it's not React specific.
Your choices
When you have state, especially good old this.state and this.setState you have to use React.PureComponent (or React.Component if you must).
For stateless functions, where you're just getting some props in, perhaps massaging them and rendering some JSX, you have choices.
You can write a React component in these three different ways:
Component
class MyComponent extends React.PureComponent {
render() {
return <h1>Hello {this.props.name}</h1>
}
}
Component function
const MyComponent = ({ name }) => {
return <h1>Hello {name}</h1>
}
Plain function
const MyComponent = name => {
return <h1>Hello {name}</h1>
}
The first two can be used like this:
return (
<div>
<MyComponent name="Peter"/>
</div>
)
The last one can be called directly:
return (
<div>
{MyComponent("Peter")}/>
</div>
)
To be exact, you can actually call the second, component function, like this too:
return (
<div>
{MyComponent({name: "Peter"})}
</div>
)
Example CodeSandbox here.
Each one has its strength and weaknesses.
Pros & cons for class MyComponent extends React.PureComponent
- You have access to life-cycle hooks such as
componentDidMount.
- It's easy to add class-level public field functions, e.g.
onButtonClick = event => {...} if inlining isn't convenient.
- It has a
shouldComponentUpdate method which means it can avoid a potentially expensive render execution when the props (or state) haven't changed.
- If you decide you want to add some state, you just need to add a constructor that sets up
this.state = {...}
- If you use
prop-types you can, depending on your babel transforms, set it as a static class member inside the class without having to repeat the name of the component outside (e.g. not having to do MyComponent.propTypes = {...} outside)
- Maybe slower. I heard this rumor. Let's see later if it checks out.
- Doesn't feel as simple because it's not a regular old function.
- Might make you feel uncertain that it might have side-effects that aren't obvious.
Pros & cons for const MyComponent = (...) =>
- Clearly it's just doing one thing. Rendering. No buts, ifs, or maybes.
- Doesn't say React all over and thus should be easy to reason about outside React, such as in a unit test.
- If it doesn't have to do all the mounting life-cycle hooks, perhaps that's valuable time saved.
- There's something hip about writing functions and feeling "functional" without all that verbosity and boilerplate like
class and extends and render etc.
- Maybe faster. We'll see.
Benchmarking the difference
I don't know with confidence if this is the right way to test this but I really wanted to avoid process.env.NODE_ENV==='development' and I wanted to run each variant a bunch of times, because it feels more realistic, so as to avoid the slowness of the initial mounting.
So I made an app that looks like this:
class Components extends React.Component {
render() {
return <Component100 count={this.props.count} />;
}
}
export default Components;
class Component100 extends React.PureComponent {
render() {
return <Component99 count={this.props.count} />;
}
}
class Component99 extends React.PureComponent {
render() {
return <Component98 count={this.props.count} />;
}
}
class Component1 extends React.PureComponent {
render() {
return <Component0 count={this.props.count} />;
}
}
class Component0 extends React.PureComponent {
render() {
collect('Components', performance.now());
return <h1>Component0: {this.props.count}</h1>;
}
}
This long chain of components calling "sub-components" starts right after the prop at the top changes. In the App that parents all of the variants, when the state changes the props change and it trickles down to that final last component. By taking a timestamp right before changing the state and during that last render you get a rough timeline for how long the whole chain took to render.
See the variants here:
Perhaps it's best to skim the code of the App.js too. It's a bit messy and there's a bunch of whacky code that uses global window to log all the timestamps but the gist is that it measures the few milliseconds it takes before a re-render is triggered until the final components render function gets called.
The app has a little hacky interval function that randomly switches between the different variants every 2 seconds and every 300 milliseconds it clicks a button, which changes the state which triggers a re-render.
Benchmark results
| Component style |
Median |
Comparison |
| Components |
3.46ms |
100% |
| ComponentFunctions |
3.04ms |
14% faster |
| Functions |
2.02ms |
71% faster |
This was done using React 16.2.0 with process.env.NODE_ENV === 'production' in Firefox 60.
You can try for yourself here: https://peterbe.github.io/function-or-component/
It might break when you click Reset. If it doesn't work very well in github.io, just download it and test locally.
Discussion
Here's my rule of thumb, the life-cycle hooks are awesome. I often write a component, using ...extends React.PureComponent even though it could be a plain function. But over time, eventually you expand it and realize you need some life cycle hook. Or you might find that writing inline functions is getting messy. Or, you realize that this component is sometimes unnecessarily called by a more complicated parent, with the same props as last time!
The performance penalty, for using full React components, is small. It exists, but it's probably dwarfed by other costs such as mounting not to mention actual DOM updating. It's also very likely that your components could benefit more from avoiding render (which only shouldComponentUpdate really can do) than the cost of calling it. Meaning, if the slower component only has to render 500 times, marginally slower, than the function component rendering 1,000 times, then the slower sometimes-not-needing-to-render will eventually win the performance battle.
There is still value in the functional stateless component. See the pros & cons above. But one rule of thumb I have is that if the component is really simple and contains no fancy logic that might affect its rendering or not rendering, then use components as functions. They're "sending a message" (to the code reader) by being brief and simple. For example, I have this little snippet in my Common.js module:
export const formatFileSize = (bytes, decimals = 0) => {
if (!bytes) return '0 bytes'
const k = 1024
const dm = decimals + 1 || 3
const sizes = ['bytes', 'KB', 'MB', 'GB', 'TB', 'PB', 'EB', 'ZB', 'YB']
const i = Math.floor(Math.log(bytes) / Math.log(k))
return parseFloat((bytes / Math.pow(k, i)).toFixed(dm)) + ' ' + sizes[i]
}
It's got nothing to do with React and that becomes extra obvious simply my looking at it. It's cleary got just one job. It's used a lot and often by more complicated components.
Last but not least; I'm very aware that the much more experienced React gurus of the world have already said something similar but with more accuracy. But I didn't want to just blurt out my opinion without adding some meat and some numbers to it. And I've always disliked the confusion that there's a choice at all so hopefully this blog post will help someone else who still suffers from having to wonder when to use which.
This tweet sums it up well:
