question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Should the Components really extend PureComponent?

See original GitHub issue

Hey, really awesome library, thanks so much for sharing!

tl;dr

I think that all Components that use render props should extend Component, instead of PureComponent.

Longer version

My colleague noticed that the <Form> component is a PureComponent, so he thought it’d be a good idea to maintain referential identity between renders, and define the render function in such a way that it would allow <Form> to opt-out of rerendering. Like so:

class Form2 extends Component {
  renderForm = ({ handleSubmit }) => {
    ...fancy rendering stuff
  };

  render() {
    return <Form render={this.renderForm} />;
  }
}

This works fine, as long as renderForm is a pure function, solely depending on it’s own parameters. However, as soon as you mix in state or props from the wrapping component (Form2 in the example), the renderForm function passed to <Form> will become stale.

This is all much better explained in the excellent article by @ryanflorence: https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578

I think the quote most relevant for this issue is the following:

That means an inline render prop function won’t cause problems with shouldComponentUpdate: It can’t ever know enough to be a PureComponent.

As I understand it, if you use render props, you should never extend PureComponent, since you don’t know what’s going on inside the render function.

What are your thoughts?

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:3
  • Comments:8 (2 by maintainers)

github_iconTop GitHub Comments

1reaction
edorivaicommented, Feb 9, 2018

For what it’s worth, I asked around on twitter. Seems like it’s really preferred not to extend PureComponent when using render props.

Thread: https://twitter.com/EdoRivai/status/961930580702253056

Also, as quoted from the official React docs:

In cases where you cannot bind the instance method ahead of time in the constructor (e.g. because you need to close over the component’s props and/or state) <Mouse> should extend React.Component instead.

1reaction
klis87commented, Feb 9, 2018

@edorivai good point with inlined render function, indeed PureComponent is always slower than Component without any benefit in this case.

I think you started a good discussion 😃

Read more comments on GitHub >

github_iconTop Results From Across the Web

When to Use React.PureComponent - Better Programming
If you've used React, then you're familiar with React.Component. It's probably what you're extending every time you create a new stateful component.
Read more >
React Component OR React PureComponent - Stack Overflow
Yes, you can but trying using Functional component more and more. In case of Class component, keep it small and extend it to...
Read more >
shouldComponentUpdate and Pure Components
In a pure component, shouldComponentUpdate is a check that does a shallow check on each prop and state value for the component.
Read more >
When to use Component or PureComponent - codeburst
It is safe to use PureComponent instead of Component so long as you follow two simple rules: 1) Mutations are bad in general,...
Read more >
React PureComponent Pitfalls | Shakacode
React calls the shouldComponentUpdate method to determine whether or not it should re-render your component. PureComponent modifies the ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found