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

Possible issue in "Components and Props" section of docs - functional vs. class components #639

Open
mbrowne opened this issue Feb 22, 2018 · 2 comments

Comments

@mbrowne
Copy link

mbrowne commented Feb 22, 2018

The current documentation says:

The simplest way to define a component is to write a JavaScript function:
[...]
You can also use an ES6 class to define a component:
[...]
The above two components are equivalent from React’s point of view.

I just encountered a contradictory comment from @trueadm, an engineer on the React core team:

In React 16, functional components are quite a bit faster than class components. On a side note, this optimization is something we’re aware of and have been talking about a bit recently. :)

https://medium.com/@trueadm/in-react-16-functional-components-are-quite-a-bit-faster-than-class-components-1afca4931d7c

Does this mean that the possible future optimizations for functional components that were mentioned in previous versions of the docs and blog posts have now been implemented? If so, this should be mentioned in the docs (and probably should have been in the release notes for React 16 too, but I don't see it mentioned there).

If this has indeed been implemented, then it should also be noted that this is a micro-optimization that still pales in comparison with using PureComponent (or your own efficient shouldComponentUpdate() logic), as explained in facebook/react#5677 (comment):

For complex components, defining shouldComponentUpdate (eg. pure render) will generally exceed the performance benefits of stateless components. The sentences in the docs are hinting at some future optimizations that we have planned, whereby we won't allocate an internal instance for stateless functional components (we will just call the function). We also might not keep holding the props, etc. Tiny optimizations. We don't talk about the details in the docs because the optimizations aren't actually implemented yet (stateless components open the doors to these optimizations).

@trueadm
Copy link
Member

trueadm commented Feb 22, 2018

Functional components in React 16 don't go through the same code path as class components, unlike in previous version where they were converted to classes and would have the same code path. Class components have additional checks required and overhead in creating the instances that simple functions don't have.

These are micro-optimizations though and shouldn't make a huge difference in real-world apps – unless your class component is overly complex. I've not benchmarked functional components vs class components with the latest version of React, but it would be interesting if someone did to see the differences today given the amount of tweaks that have happened in JS engines since I last benchmarked.

@mbrowne
Copy link
Author

mbrowne commented Feb 23, 2018

Thanks @trueadm - very good to know, even though it's a just a micro-optimization. So it's as I said above - using PureComponent would make a much bigger difference.

I still think both of these points should be mentioned in the docs. It's misleading to just say, "The above two components are equivalent from React’s point of view" and leave it at that. That introductory section isn't the right place to get into tiny nuances of performance differences, but it could have a link to a more advanced section with notes about performance. I might submit a PR.

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

2 participants