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

Stateless functional components and shouldComponentUpdate #5677

Closed
slorber opened this issue Dec 16, 2015 · 42 comments
Closed

Stateless functional components and shouldComponentUpdate #5677

slorber opened this issue Dec 16, 2015 · 42 comments

Comments

@slorber
Copy link
Contributor

@slorber 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
Copy link
Contributor

@jimfb 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
Copy link
Contributor Author

@slorber 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
Copy link
Contributor

@jimfb 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
Copy link
Contributor Author

@slorber 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
Copy link
Contributor

@jimfb 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
Copy link
Contributor Author

@slorber 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
Copy link
Contributor

@jimfb 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
Copy link
Contributor Author

@slorber 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
Copy link
Contributor

@jimfb 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
Copy link

@tjconcept tjconcept commented Jan 8, 2016

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
Copy link
Contributor

@jimfb 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
Copy link

@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/

@idrm
Copy link

@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
Copy link

@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
Copy link
Member

@gaearon 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
Copy link

@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
Copy link

@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
Copy link

@shishirarora3 shishirarora3 commented Aug 21, 2016

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
Copy link

@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
Copy link

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

@jwcone
Copy link

@jwcone jwcone commented Feb 19, 2017

@Recmo

I'm new to React, so I welcome any correction/explanation, but I think you'd want to include a defaultProps assignment in your pure() function:

PureComponentWrap.defaultProps = func.defaultProps

Also, as a tangent, is this basically the HOC wrap approach that slorber mentioned, earlier?

@clayne11
Copy link

@clayne11 clayne11 commented Mar 15, 2017

You shouldn't use defaultProps for functional components. You should use the language and use default parameters in the function.

@Klaasvaak
Copy link

@Klaasvaak Klaasvaak commented Mar 23, 2017

Should this do the trick?

var Aquarium = ({species}) => (
  <Tank>
    {getFish(species)}
  </Tank>
);
Aquarium.prototype.isPureReactComponent = true;
@mir3z
Copy link

@mir3z mir3z commented Mar 24, 2017

To sum up the discussion... The current state is that functional components are always re-rendered even if props are unchanged, right?

How is that different from non-functional components? Correct me if I'm wrong but my understanding is that React does not compare props or state itself unless you provide shouldComponentUpdate. On the other hand it compares virtual dom representation to find out what actually have changed.

@jooj123
Copy link

@jooj123 jooj123 commented Mar 26, 2017

@mir3z

To sum up the discussion... The current state is that functional components are always re-rendered even if props are unchanged, right?

Correct.

How is that different from non-functional components?

You can provide a shouldComponentUpdate check with these and prevent the diffing algorithm from being run - potentially adding some performance gains.
Both functional and non-functional use the same dom diffing process from my understanding

@davidworkman9
Copy link

@davidworkman9 davidworkman9 commented Mar 29, 2017

@Klaasvaak

Should this do the trick?

var Aquarium = ({species}) => (
  <Tank>
    {getFish(species)}
  </Tank>
);
Aquarium.prototype.isPureReactComponent = true;

Looks like it doesn't. https://jsfiddle.net/a6ehwonv/92/

@Klaasvaak
Copy link

@Klaasvaak Klaasvaak commented Mar 30, 2017

@davidworkman9 was looking at this code here: https://github.com/facebook/react/blob/v15.4.2/src/renderers/shared/stack/reconciler/ReactCompositeComponent.js#L70 and thought that it might work. But I guess it doesn't

@msuperina
Copy link

@msuperina msuperina commented Apr 10, 2017

I started working at this small library that may be helpful in such situations.
https://github.com/msuperina/react-cache
It is definitely just a start as there may be many more optimizations to do.

@Huxpro
Copy link

@Huxpro Huxpro commented Jun 21, 2017

It's surprising that functional component not PureComponent by default...

@a8568730
Copy link

@a8568730 a8568730 commented Jul 21, 2017

I wrap my functional components with Recompose.pure.

const ExpensiveChild = ({children}) => {
  return(
  <p>Hi {children}</p>
)}

const PureChild = Recompose.pure(ExpensiveChild)

Codepen

@felquis
Copy link

@felquis felquis commented Jul 31, 2017

I improved @davidworkman9's example #5677 (comment) ... here -> https://jsfiddle.net/tynt7te9/ and updated to 15.6.1

I realized the best thing to do is to use:

class PureComponent extends React.PureComponent {
  render () {
    console.count('PureComponent')
    return <div>React.PureComponent: {this.props.render}</div>
  }
 
  shouldComponentUpdate: false
}

https://jsfiddle.net/tynt7te9/1/ pretty cool

@danny-andrews
Copy link

@danny-andrews danny-andrews commented Sep 27, 2017

It's surprising that functional component not PureComponent by default...

Although it's somewhat counter-intuitive, I think it actually makes sense that functional components are not PureComponent by default. The only guarantee (correct me if I'm wrong) React has with functional components that it doesn't have with class-based is that they don't have any internal state. People could still be mutating their props in the wild and relying on their components to re-render, making this a breaking change. (I agree, however, that there should be some way to opt-in to this behavior in the interim.)

@jonaskello
Copy link

@jonaskello jonaskello commented Apr 5, 2018

Above it is mentioned that in the future there might be a way to opt-in to pure functional components. Is there an issue I can follow to see the progress on this? I've found this issue but it is closed so I guess there is no point to follow along here.

Btw, if such and option would be implemented, I think it would be nice if it could be applied at a global level rather than having to set it on every function.

@mrchief
Copy link

@mrchief mrchief commented Apr 13, 2018

Recompose.pure is simply a wrapper around React's Component and shallowEqual. Wondering what's the benefit of using that vs just extending Component/PureComponent (and avoid packing extra pounds).

@danny-andrews
Copy link

@danny-andrews danny-andrews commented Jul 13, 2018

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

@jimfb Can you share this benchmark? Maybe things have changed since 2015, but it appears string comparison is quite fast, and the most JS implementations use string interning. https://stackoverflow.com/questions/5276915/do-common-javascript-implementations-use-string-interning

@skipjack
Copy link

@skipjack skipjack commented Jan 11, 2019

For anyone who's still stumbling on this, React.memo was released recently which is an easy built-in way to create a pure, stateless component:

https://reactjs.org/docs/react-api.html#reactmemo

@mrchief
Copy link

@mrchief mrchief commented Jan 11, 2019

Better than memo, what you're looking for is React hooks

@mqklin
Copy link

@mqklin mqklin commented Feb 7, 2019

@mrchief you can't use Hooks to solve this problem

@mrchief
Copy link

@mrchief mrchief commented Feb 7, 2019

@mqklin Why do you say that? I'm going based on the OP, maybe I missed something down the thread?

@mqklin
Copy link

@mqklin mqklin commented Feb 8, 2019

Sorry, I had to explain.
Hooks can't cancel update like memo can. You can't use Hooks to control render. Can you provide an example?
For memo it's simple:

export default memo(YourFunctionalComponent);
@mrchief
Copy link

@mrchief mrchief commented Feb 8, 2019

Hooks can't cancel update like memo can. You can't use Hooks to control render. Can you provide an example?

Sure you can. In fact, hooks can go beyond React.Memo in some use-cases. React.Memo avoids (or cancels as you call it) updates by doing a "shallow" compare of the props. In that sense, it'll fail to prevent the update if you use deep objects or objects that have function refs. Hooks can help you in those cases as well.

First of all, if you have shallow components, the simple useState hook can help you avoid re-renders.

Secondly, if you have nested parent/child structure and you want to avoid child re-renders on parent update, there is useMemo which lets you memoize the renders:

const yourComponent = useMemo(() => <YourFunctionalComponent a={a} b={b}), [a, b]);

This is equivalent to shouldComponentUpdate where your component will only render if a or b has changed (or whatever props you pass in the 2nd argument array).

Then there's useCallback hook that lets you keep the same function ref so SCU works.

Finally there's useReducer hook that let's you deal with deep objects.

You can find all of this info in the FAQs; specifically in How do I implement shouldComponentUpdate? and Are Hooks slow because of creating functions in render?.

I'm not saying no one should use React.memo (as useMemo and hooks in general have some constraints where React.memo might be a better choice) rather trying to highlight the fact that we now have more options and choices in our toolbelt.

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

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.