Stateless functional components and shouldComponentUpdate #5677

Closed
slorber opened this Issue Dec 16, 2015 · 20 comments

Projects

None yet

8 participants

@slorber
Contributor
slorber commented Dec 16, 2015

This is probably a question / documentation issue.

var Aquarium = ({species}) => (
  <Tank>
    {getFish(species)}
  </Tank>
);

In some places of the doc we can read:

https://facebook.github.io/react/docs/reusable-components.html

In an ideal world, most of your components would be stateless functions because these stateless components can follow a faster code path within the React core. This is the recommended pattern, when possible.

https://facebook.github.io/react/blog/2015/10/07/react-v0.14.html

This pattern is designed to encourage the creation of these simple components that should comprise large portions of your apps. In the future, we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations.

What I find unclear is these explainations is how React optimize the rendering when using stateless functional components. The good sense would be that React uses something similar to shallowEqual to know if it has to call the function or not, but as React does not enforce strict immutability yet (I mean the PureRenderMixin is actually an option, not the default), I wonder how these functional components behave.

I think this should be better documented if any memoization technique is used when rendering these functional components, because it's not so obvious to me if my app will perform almost the same (or better) if I choose to replace all my components using PureRenderMixin and no state/lifecycle methods by functional components as I don't have much insights of the internal working of the optimizations done.

@jimfb
Contributor
jimfb commented Dec 16, 2015

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).

@slorber
Contributor
slorber commented Dec 17, 2015

Thanks

So what I understand is that currently functional components do not memoize their execution based on shallowCompare of props right? Couldn't it be implemented easily?

@jimfb
Contributor
jimfb commented Dec 17, 2015

Correct. Such memoization would break any application that was not using immutable data, because the "optimization" would be making an assumption that the root prop reference changes when the data changes. Imagine that the prop is an array, pushing to the array would not show up in a shallowCompare, which is why that optimization is not valid by default.

@slorber
Contributor
slorber commented Dec 17, 2015

So how can I use that memoization with a functional component? Will I be able to do so in the future?

I guess I could wrap it in an HOC but this then probably defeats the purpose of using functional components for the coming little optimizations that can be done

@jimfb
Contributor
jimfb commented Dec 17, 2015

There are discussions about having a pureRender flag that you could set on the function, or allowing it to participate in the shouldUpdate lifecycle, but that's currently not implemented. At the moment, stateless functions can not be pure-render.

It is worth keeping in mind that sometimes people abuse/overuse pure-render; it can sometimes be as or more expensive than running the render again, because you're iterating over the array of props and potentially doing things like string compares, which is just extra work for components that ultimately return true and then proceed to rerender anyway. PureRender / shouldComponentUpdate really is considered an escape hatch for performance and is not necessarily something that should be blindly applied to every component.

@slorber
Contributor
slorber commented Dec 17, 2015

I would be happy to have that flag.

yes I understand that however in most cases where we start to compare primitive values there's generally a parent that may already have memoized the rendering. It's often the data is coming from an API or is stored in objects so your primitives are probably in an immutable object at first before being dispatched to deeper components, thus giving the dispatcher parent to block rendering.

I think in ELM or Om this is applied by default to all the tree and works pretty well.

Is it that bad to compare strings vs comparing object identities? I guess strings hashes are compared first no?

@jimfb
Contributor
jimfb commented Dec 17, 2015

Elm and Om are both far more functional/immutable than general javascript, which is probably why it makes more sense there. We are supporting standard javascript as a target language, and javascript is a language where mutability is common.

My perf benchmarks have found string compares to sometimes be quite slow (just doing string-compares of the prop-names with pre-defined values that we need to handle specially, and that isn't even arbitrarily long data compares). Hash comparison can only detect miss-matches, but can not guarantee that two strings are equal (due to collisions), so to prove equality you still need to walk the whole string, but your assumption is that the two strings are equal in the common case, otherwise why would you be using pure-render (ie. with hashing, you still need to walk the whole string in the supposed common case). String pooling does a better job than hashing, but it starts to get complicated.

Anyway, we digress. The simple answer is: no, we don't do pure render by default, but we may provide a way for you to opt-in in the future.

@slorber
Contributor
slorber commented Dec 17, 2015

so this is fine :)

I don't know so much about the javascript's inner working but coming from Java world we have string pooling built-in so I may assume wrong things about js :)

@jimfb
Contributor
jimfb commented Dec 17, 2015

I also come from a Java background. Java's pooling works pretty well, but you still can't depend on str1 == str2 in Java, for exactly the reason that pooling is not guaranteed by the JVM because "it starts to get complicated".

@tjconcept

Interesting read. I assumed functional components would be "pure render" by default when seeing the syntax and reading the blog post about 0.14.

@jimfb
Contributor
jimfb commented Jan 8, 2016

I'm going to close this out, since it was mostly a discussion thread and there is nothing actionable here.

@jimfb jimfb closed this Jan 8, 2016
@giltig
giltig commented Jan 18, 2016

Hi, the action that I think should be here is memoization by default of stateless functions of React.
Here is an example of doing it manually - notice the diffs in the console.log...:
https://jsfiddle.net/giltig/a6ehwonv/28/

@cerisier cerisier referenced this issue in jxnblk/rebass Mar 11, 2016
Closed

Components are not pure #47

@vdh vdh referenced this issue in yannickcr/eslint-plugin-react Mar 15, 2016
Closed

react/prefer-stateless-function false positive #491

@n1k0 n1k0 referenced this issue in mozilla-services/react-jsonschema-form Mar 17, 2016
Merged

Added shallow comparison checks to stateful components. #70

@n1k0 n1k0 referenced this issue in mozilla-services/react-jsonschema-form Apr 20, 2016
Closed

Slow performance #147

@idrm
idrm commented Jun 21, 2016

@giltig, Your memoization function will not work as intended when there are multiple instances of the same component with different properties.

@jooj123
jooj123 commented Aug 20, 2016

Is there any sort of rule of thumb for react being quicker for a component to render with many stateless functions or many classes with shouldComponentUpdate shallow equals.
Or is it something that needs to be profiled for every use case?

In my case there is many small components that are very small and are constantly mounted and unmounted.

I assume there will massive perf savings in mounting / unmounting for stateless because there is no lifecycle ?

@gaearon
Member
gaearon commented Aug 20, 2016

There are currently no special optimizations done for functions, although we might add such optimizations in the future. But for now, they perform exactly as classes.

@jooj123
jooj123 commented Aug 20, 2016

fair enough - after running through parts of the react source, i can see that stateless functions still mount like regular classes

@giltig
giltig commented Aug 21, 2016

@idrm Hi, but that's all the point. Memoization works when you give the component the same props which is exactly what we want, so it will only trigger render for components who receives different props thus getting pure rendering for stateless components as well (without shouldComponentUpdate)

@shishirarora3

So should we memoize or is it already done in react code?

On Sun, 21 Aug 2016 19:53 giltig, notifications@github.com wrote:

@idrm https://github.com/idrm Hi, but that's all the point. Memoization
works when you give the component the same props which is exactly what we
want, so it will only trigger render for components who receives different
props thus getting pure rendering for stateless components as well (without
shouldComponentUpdate)


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5677 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIKvJuUgyQZo23Qyx13sCem88jI8yC3vks5qiF9rgaJpZM4G2hkT
.

@giltig
giltig commented Aug 21, 2016

There is a library
https://www.npmjs.com/package/memoization
You can use and just memoize all your stateless components (in export for example)

@idrm
idrm commented Aug 27, 2016

@giltig, what I'm saying is that your memoization function (purify) is, essentially, a component instance cache with a bucket size of 1 per "purified" component. I don't see how a memoize approach can become a substitute for shouldComponentUpdate the way React currently works.

@andersmurphy andersmurphy added a commit to andersmurphy/js-quiz-client that referenced this issue Dec 25, 2016
@andersmurphy andersmurphy refactors score component
Refactors score component to define it as a function that take props.
As this makes for simpler and more understandable components (they also
prevent components from having state).

For testing this required installing enzyme a test library that
simplifies shallow render testing (built on: reacts inbuilt shallow
rendering).

Note 1 - currently components as functions do not support shallow
compare that PureComponents do, unfortunately this negates one of the
many benefits of using immutable and persistent data structures.
Hopefully, this feature will be added in future.
facebook/react#5677

Note 2 - components that are defined as functions that take props
do not currently support refs.

commands:
npm i --save-dev enzyme
6123c17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment