Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write docs for React.PureComponent #7379

Closed
zpao opened this issue Jul 29, 2016 · 15 comments
Closed

Write docs for React.PureComponent #7379

zpao opened this issue Jul 29, 2016 · 15 comments

Comments

@zpao
Copy link
Member

zpao commented Jul 29, 2016

Need to at least update the top level api page, but should consider writing something more about it.

cc @spicyj

@kevinSuttle
Copy link
Contributor

The most confusing thing for me:

"Pure component" = functional stateless component, doesn't extend a class

@xiaofan2406
Copy link

@kevinSuttle wait... PureComponet === functional component ???

@albertoblaz
Copy link

Yeah, it'd be great to have some docs about this topic. Do Functional Components implement by default the same logic as React.PureComponent? If so, developers could enforce the use of:

  1. Functional Components
  2. If you need lifecycle hooks, then PureComponent
  3. If you need local state, then just a normal Component

@zpao
Copy link
Member Author

zpao commented Aug 4, 2016

"Pure component" = functional stateless component, doesn't extend a class

That's not the case. It's effectively just a base class to extend with PureRenderMixin built in.

This is why we need docs 😉

@raphaguasta
Copy link

Hello Guys!

I think we don't have a docs, so... I have one question!

If I have a dump component, that only render something. It's better to use the stateless component, or a class that extends PureComponent?

Thanks ;)

@cbengtson85
Copy link

@raphaguasta
I have the same question!

@frandsaw
Copy link

frandsaw commented Oct 8, 2016

@raphaguasta @cbengtson85 according to this code the main difference between PureComponent and StatelessComponent:

  • StatelessComponent's shouldUpdate value will be always true
  • PureComponent's shouldUpdate value is equal to the result of shallow equality check

So in your case shouldUpdate value will be false for PureComponent and true for StatelessComponent. I think it's cheaper to make shallow equality check than making a Virtual DOM comparison, but I may be wrong here.

@gaearon
Copy link
Collaborator

gaearon commented Oct 23, 2016

It is in the docs now.

@gaearon gaearon closed this as completed Oct 23, 2016
@webdif
Copy link

webdif commented Jan 3, 2017

Thanks a lot for adding some docs about React.PureComponent.

However, it's still obscur to me when use or not use it. Most of components are tied to their props and state, thus the majority of Component should be extending PureComponent? When using React component with Redux for example.

Also, I always wrote my component as StatelessComponent. But it seems that PureComponent can also be a more efficient than a StatelessComponent, as @frandsaw stated, a shallow equality check may be cheaper than a virtual dom comparison.

So my conclusion right now is "PureComponent all the things!", but I fear I may be missing something here… If you have some good examples where Component or StatelessComponent is better than a PureComponent, it would be great! Thanks a lot for your help 👍

@gaearon
Copy link
Collaborator

gaearon commented Jan 3, 2017

If something is slow then try using PureComponent and see if it helps.
If nothing is slow then don’t bother optimizing it.

There is no sure way to tell which is going to be slower: reconciliation or shallow comparisons everywhere. In pathological cases (shallow equality checks often failing) PureComponents can be slower. So the only rule of thumb is to only add one when you know you have a perf problem and you can verify adding it solves that problem. Does this help?

@webdif
Copy link

webdif commented Jan 3, 2017

Thank you @gaearon for your response, it helps!
Build first and optimize later when needed seems like the most pragmatic way.

@JLarky
Copy link

JLarky commented Mar 2, 2017

I wish there would be at least one example somewhere in docs that you can copy-paste instead of historical perspective on what was changed and what add-ons were deprecated :) I can still copy-paste code for old add-ons from the docs! why can't I get new stuff?

@gaearon
Copy link
Collaborator

gaearon commented Mar 2, 2017

I'm not sure what you mean. If I open "Optimizing Performance", it has a code example. Are you looking at some different page?

@tocttou
Copy link

tocttou commented Mar 27, 2017

I wrote a simple blog post explaining PureComponent. Hope it helps!

https://ashishchaudhary.in/using-purecomponent-to-prevent-wasted-renders-in-react

@yesmeck
Copy link

yesmeck commented Feb 21, 2019

@gaearon

In pathological cases (shallow equality checks often failing) PureComponents can be slower. So the only rule of thumb is to only add one when you know you have a perf problem and you can verify adding it solves that problem. Does this help?

I saw many people misusing PureComponent in the project. Can we add this suggestion to the docs?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests