Stateless functional components and shouldComponentUpdate

[slorber]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[giltig]

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/