Optimizing React Rendering(flexport.engineering)
flexport.engineering
Optimizing React Rendering
https://flexport.engineering/optimizing-react-rendering-part-1-9634469dca02
78 comments
That's a great point, and being aware of the dangers of shouldComponentUpdate is what this post is all about. There are a lot of gotchas when using PureComponents, and can lead to bugs if you're not careful.
Also, recalculating derived data (building static lists) in render() is very wasteful, and is also another gotcha when using PureComponents (object copying). Removing object copying from render() speeds up the actual render() call and allows you to take full advantage of PureComponents.
We are experimenting with ways to make all of this a bit easier, and hopefully will have some good news to share in Part 2 :)
Also, recalculating derived data (building static lists) in render() is very wasteful, and is also another gotcha when using PureComponents (object copying). Removing object copying from render() speeds up the actual render() call and allows you to take full advantage of PureComponents.
We are experimenting with ways to make all of this a bit easier, and hopefully will have some good news to share in Part 2 :)
Pretty good post, minus the advice to always use PureComponent everywhere (per Ben's comment in this thread).
If anyone's interested, my React/Redux links list has a large section of other articles on various React-related performance concerns, including benchmarking and optimization approaches: https://github.com/markerikson/react-redux-links/blob/master... .
If anyone's interested, my React/Redux links list has a large section of other articles on various React-related performance concerns, including benchmarking and optimization approaches: https://github.com/markerikson/react-redux-links/blob/master... .
Along the same lines as the advice in TFA: If you pass an object literal as the `style` prop, it'll always re-render, because the object reference will change. Solution: instead of the object literal, pass a reference to an existing object.
One thing that has been bothering me is that React is slow by default. It re-renders everything every time unless you start looking into shouldComponentUpdate.
Even if I agree that premature optimization is the root of all evils, I like when the language and the framework I use make it writing fast code as easy as writing slow code.
I wonder if anybody has evaluated, the improvement they get in development speed using React when they add the time they have to spend to optimizing their React code.
In my experience, I am not even frustrated with React itself most of the time but with the other things in the ecosystem.
Even if I agree that premature optimization is the root of all evils, I like when the language and the framework I use make it writing fast code as easy as writing slow code.
I wonder if anybody has evaluated, the improvement they get in development speed using React when they add the time they have to spend to optimizing their React code.
In my experience, I am not even frustrated with React itself most of the time but with the other things in the ecosystem.
Hmm, my experience has been pretty much the opposite. Even without optimization, React's renders won't cause a DOM update unless there is something to diff - I can't say the same for jQuery or Angular 1.x. As well, being big on the "don't use it unless you need it" bandwagon I tend to wait until I see components and re-use in my code before I import React in the first place.
If the total re-render is occurring under 16.67ms (60fps) in a non-trivial use-case I'm usually fine leaving it as-is. Most render cycles taking longer than that involve operations on large data sets or events firing at the millisecond level (mouseover, drag, etc) - and those are worth fixing as they'll actually have noticeable impacts on the user experience. But I tend not to optimize just to pat myself on the back for "optimization".
If the total re-render is occurring under 16.67ms (60fps) in a non-trivial use-case I'm usually fine leaving it as-is. Most render cycles taking longer than that involve operations on large data sets or events firing at the millisecond level (mouseover, drag, etc) - and those are worth fixing as they'll actually have noticeable impacts on the user experience. But I tend not to optimize just to pat myself on the back for "optimization".
In our experience, React is not necessarily 'slow' by default. Re-constructing parts of the element tree each time can be a bit wasteful, but it is only as slow as your render() methods, and that is outside of React's control.
We have survived over 3 years with a massive application (over 2000 modules) and tons of wasteful re-rendering, but have only now started to notice any sluggishness. That makes React pretty fast in my mind.
Having said all that, we are experimenting with an 'all PureComponents' approach to potentially make React, but whether that turns out to be a good idea is yet to be seen (object comparisons in sCU are not free).
We have survived over 3 years with a massive application (over 2000 modules) and tons of wasteful re-rendering, but have only now started to notice any sluggishness. That makes React pretty fast in my mind.
Having said all that, we are experimenting with an 'all PureComponents' approach to potentially make React, but whether that turns out to be a good idea is yet to be seen (object comparisons in sCU are not free).
From what I've found in my current job creating a js react app as well as side project with cljs is that advanced optimsation of js react === basic usage of clojurescript reagent.
I've found no redeeming features when developing the is app, issues with hot reloading and constant integration work to get everything to play nice with immutable js
*the js app
I'm the author of CxJS[1] which uses React for rendering. Before rendering, the whole tree is scanned for data changes and with that information available shouldComponentUpdate is very simple.
Another technique that I find very useful is to use a dedicated data declaration component which then decides if children should update or not. Try grid sorting on this page: https://worldoscope.cxjs.io/yyrsmjk
[1]: https://cxjs.io
Another technique that I find very useful is to use a dedicated data declaration component which then decides if children should update or not. Try grid sorting on this page: https://worldoscope.cxjs.io/yyrsmjk
[1]: https://cxjs.io
Would using mobx to manage state solve most of these problems?
Yeah. That's exactly what I was thinking as I read through the list of gotchas.
We've just started using mobx ourselves. There's still a weird contention between events and state that I'm yet develop patterns for but overall I'm really happy with it.
We've just started using mobx ourselves. There's still a weird contention between events and state that I'm yet develop patterns for but overall I'm really happy with it.
This is actually a pretty decent article, in part because it signals its audience properly: (semi-?)experienced React developers who haven't dealt with optimization yet.
so basically the Facebook app team?
Edit: sorry guys, didn't knew you were all on HN :(
Edit: sorry guys, didn't knew you were all on HN :(
Anyone else sick of the incredibly lazy "shill"-type accusations being thrown around lately? Just because a post is heavily upvoted or downvoted does not mean the team behind the post is brigading or manipulating it. Let's loosen those tinfoil hats just a bit.
This was all said on jest, chill man!
But now that we are at it, why don't you give me another probable reason a harmless comment was downvoted?
But now that we are at it, why don't you give me another probable reason a harmless comment was downvoted?
The downvotes are sad. Are people this far gone that they can't take a little criticism?
Offtopic, but regarding the downvotes -
I have been using FB front-end projects for several years, and today I see them as _the_ gold standard for a supportive, mature, well-governed, and consistent FoSS ecosystem. I struggle to recall any snarkiness, cynicism, or even rudeness. I'm sure it happens, but I closely monitor several of their projects and the behavior is mostly exemplary even without considering the size of the user-base.
Besides near-exemplary FoSS behavior, FB engineers must solve problems well beyond what most industry will ever attempt, and then present some of their solutions on a silver platter for the rest of us. Of course, it's not perfect, and sometimes confusing, and sometimes over-engineering, but I would personally pay $xx,000 per year to use any library of the same standard as they give out for free.
So when I see a callous comment that takes nothing to write and could cause someone to feel degraded about their vast contributions, I downvote. It's not about safe places, it's about professional respect and courtesy.
I have been using FB front-end projects for several years, and today I see them as _the_ gold standard for a supportive, mature, well-governed, and consistent FoSS ecosystem. I struggle to recall any snarkiness, cynicism, or even rudeness. I'm sure it happens, but I closely monitor several of their projects and the behavior is mostly exemplary even without considering the size of the user-base.
Besides near-exemplary FoSS behavior, FB engineers must solve problems well beyond what most industry will ever attempt, and then present some of their solutions on a silver platter for the rest of us. Of course, it's not perfect, and sometimes confusing, and sometimes over-engineering, but I would personally pay $xx,000 per year to use any library of the same standard as they give out for free.
So when I see a callous comment that takes nothing to write and could cause someone to feel degraded about their vast contributions, I downvote. It's not about safe places, it's about professional respect and courtesy.
Seriously? HN has really short memory...
https://news.ycombinator.com/item?id=11057857
https://news.ycombinator.com/item?id=10066338
https://news.ycombinator.com/item?id=14082491
https://news.ycombinator.com/item?id=11057857
https://news.ycombinator.com/item?id=10066338
https://news.ycombinator.com/item?id=14082491
What's the real criticism in his or her post? I see nothing other than a completely unsubstantiated accusation.
seems like the complaint is facebook=slow. Would you say that facebook is a good example of a fast site\app?
Quick question - can printWasted be used with RN too?
Haven't tried this myself, but this might be what you're looking for: https://github.com/facebook/react-native/issues/9146#issueco...
Thanks! I'll give it a go.
From the article:
> Fixing the issue is pretty simple*. We simply need to short circuit the re-rendering for a subtree if we know that the subtree hasn’t changed.
Not a frontend guy but I've seen this theme more than once on HN recently. It seems to me that addressing this anti-pattern would be built right in to modern React components. Isn't efficient DOM manipulation by pruning non-necessary changes kind of their thing?
> Fixing the issue is pretty simple*. We simply need to short circuit the re-rendering for a subtree if we know that the subtree hasn’t changed.
Not a frontend guy but I've seen this theme more than once on HN recently. It seems to me that addressing this anti-pattern would be built right in to modern React components. Isn't efficient DOM manipulation by pruning non-necessary changes kind of their thing?
It is, so a DOM change wouldn't occur, but in these cases you still go through a React rendering to virtual DOM phase (templating) and the DOM tree reconciliation.
Since these can be slow (although much faster than a DOM change), it makes sense to check and skip those steps when you can.
The focus of most of this article is how you can skip those steps when you're components input data is unchanged and common gotchas related to that.
Some other great posts in this vein are: https://facebook.github.io/react/docs/optimizing-performance... and http://benchling.engineering/performance-engineering-with-re...
Since these can be slow (although much faster than a DOM change), it makes sense to check and skip those steps when you can.
The focus of most of this article is how you can skip those steps when you're components input data is unchanged and common gotchas related to that.
Some other great posts in this vein are: https://facebook.github.io/react/docs/optimizing-performance... and http://benchling.engineering/performance-engineering-with-re...
Efficient DOM manipulation is their thing.
But that sentence is talking about VirtualDOM rendering - which still takes time - not DOM manipulation.
Basically it's saying "if we don't need to do work, we shouldn't". Which React already does for DOM manipulation and this kind of optimization does it for virtualDOM creation.
But that sentence is talking about VirtualDOM rendering - which still takes time - not DOM manipulation.
Basically it's saying "if we don't need to do work, we shouldn't". Which React already does for DOM manipulation and this kind of optimization does it for virtualDOM creation.
React won't update the DOM when render returns the same result but if you can avoid those unnecessary render calls you save some scripting time. Front-end developers have to be very conservative when it comes to running JS code. Welcome to single threaded everything programming!
I think it is an anti-pattern that is a result of the language it's built on.
This is one place where using Clojurescript wrappers of React has a real payoff - immutable datastructures make equality checking very very cheap.
This is one place where using Clojurescript wrappers of React has a real payoff - immutable datastructures make equality checking very very cheap.
A good patch for this is ImmutableJS
Is there special logic in react that binds arguments of a function to the props with the same name? I'm talking about the handleDelete "fix" in the article:
render() {
const views = this .props.dataList.map((d, i) => {
return <Data data={d} index={i} />
});
}
handleDelete(index) {
//...
}
By using the property initializer syntax [1] [2]
[1] https://facebook.github.io/react/docs/handling-events.html
[2] https://babeljs.io/docs/plugins/transform-class-properties/
[1] https://facebook.github.io/react/docs/handling-events.html
[2] https://babeljs.io/docs/plugins/transform-class-properties/
That solves the problem of binding 'this', but doesn't solve the problem of supplying the index to the callback function. Essentially you have only two options for doing that.
One is to bind the callback function to a certain index in advance and then supply that callback to your child via props so it already knows the relevant index and doesn't need calling with any extra parameters. The trouble with this one is that it creates a new function every time, which is inefficient in itself and horrible if it winds up causing your child to rerender because props changed even though in practice you're passing an identical function every time.
The other is to supply a callback where the child component is responsible for supplying the extra index information when it calls the function, either by directly passing the index as a parameter or via an indirect route such as using data-* attributes as 'kentor mentioned. This is more efficient, but it creates tighter coupling between the child and parent components.
In practice, it seems most projects adopt the second strategy because the tighter coupling is usually much less of a problem in practice than the performance penalty, but neither solution is ideal. Unfortunately, JavaScript's semantics don't make it easy to have the equivalent of a "deep equal" comparison on functions that would return true for two copies of the same function with the same bound values.
One is to bind the callback function to a certain index in advance and then supply that callback to your child via props so it already knows the relevant index and doesn't need calling with any extra parameters. The trouble with this one is that it creates a new function every time, which is inefficient in itself and horrible if it winds up causing your child to rerender because props changed even though in practice you're passing an identical function every time.
The other is to supply a callback where the child component is responsible for supplying the extra index information when it calls the function, either by directly passing the index as a parameter or via an indirect route such as using data-* attributes as 'kentor mentioned. This is more efficient, but it creates tighter coupling between the child and parent components.
In practice, it seems most projects adopt the second strategy because the tighter coupling is usually much less of a problem in practice than the performance penalty, but neither solution is ideal. Unfortunately, JavaScript's semantics don't make it easy to have the equivalent of a "deep equal" comparison on functions that would return true for two copies of the same function with the same bound values.
Another is to wrap the first option in _.memoize so you only create functions once per argument and you don't get unnecessary rerenders. Just remember that _.memoize only uses the first arg for cache lookups.
> I guess they just call that function from within the Data component with the correct parameter.
Yep
> Is there a better way?
We're experimenting with some other options internally. Once we have a better sense of what works best, we will post another article on our learnings :)
Yep
> Is there a better way?
We're experimenting with some other options internally. Once we have a better sense of what works best, we will post another article on our learnings :)
Assuming your "deleteDataAt" function is a Redux action creator that dispatches an action to delete the list item -- if this is the case, then continue passing that action creator as a prop to the child, and since you've also passed down the index, the child can simply apply that action creator as the event listener. Eg. in the code snippet you've provided, I would have just done:
return ( <Data value={d} index={i} deleteDataAt={deleteDataAt} /> );
Then your onClick in the child would be: => this.props.deleteDataAt(this.props.index);
Correct me if I'm missing anything!
return ( <Data value={d} index={i} deleteDataAt={deleteDataAt} /> );
Then your onClick in the child would be: => this.props.deleteDataAt(this.props.index);
Correct me if I'm missing anything!
> Correct me if I'm missing anything!
You're not missing anything :) That approach also works. The important point is that you have to pass the extra index prop down to the child to avoid the bind in render.
You're not missing anything :) That approach also works. The important point is that you have to pass the extra index prop down to the child to avoid the bind in render.
[deleted]
Nope. For dom elemenets I have been using `data-{name}` attributes, and pulling them out from the handler using `e.currentTarget.dataset.{name}`
You can partially apply the function where you know the parameter; i.e. assign onDelete to:
this.handleDelete.bind(this, i)
The reason arrow functions and bind don't play well with PureComponents is that they return a new function instance each time. This means that the Data pure component will wastefully re-render even if none of the other props change.
Only if you did that in the render function.
If you did this.foo = this.foo.bind(this, props.bar) in the constructor then it would be the same function each time.
If you did this.foo = this.foo.bind(this, props.bar) in the constructor then it would be the same function each time.
For this specific example you don't have access to the list index in the constructor.
In general binding like that in the constructor works only if you depend on props, but at that point, there isn't a need to bind at all since you can just reference the prop in the callback.
In general binding like that in the constructor works only if you depend on props, but at that point, there isn't a need to bind at all since you can just reference the prop in the callback.
If you do that in the parent constructor it only really works for a single child and then you're better off not partially evaluating and instead having it pull props.bar at execution time
Sure, it would be an odd pattern but perhaps a required one for a certain interface.
eg: it's going to be used as a event callback but you want the function signature to be foo(bar, event). Then you get the benefits of partial application without the problems of currying a new function each time its called.
source: have used this a lot for event handlers, especially when dealing with on 3rd party code.
eg: it's going to be used as a event callback but you want the function signature to be foo(bar, event). Then you get the benefits of partial application without the problems of currying a new function each time its called.
source: have used this a lot for event handlers, especially when dealing with on 3rd party code.
I don't quite understand. The interface is the same. I guess if the function you're binding is an external 3rd party one then you avoid proxying through a local function first. But there's no difference from the point of view of the child.
I guess my point was that it doesn't scale to multiple children (which is effectively what the question was about). And whether you want to partially apply a bound function in the constructor or just bind and then have the function pick up the extra arg itself - it's the same thing. You end up with a single function that works with a single constant.
Though, in your case if props change, the partially applied function is now incorrect. Which is why I think I'm misunderstanding you.
I guess my point was that it doesn't scale to multiple children (which is effectively what the question was about). And whether you want to partially apply a bound function in the constructor or just bind and then have the function pick up the extra arg itself - it's the same thing. You end up with a single function that works with a single constant.
Though, in your case if props change, the partially applied function is now incorrect. Which is why I think I'm misunderstanding you.
Right, I just used `props.bar` in that example, you're right - it would be a bad idea to do so unless it was some kind of initializing prop (common with state-based stuff).
> The interface is the same.
Huh? foo(event) is different from foo(bar, event) and if your function is only ever going to be called with the former (ie - any dom event handler) and you want the latter... it's absolutely useful.
> The interface is the same.
Huh? foo(event) is different from foo(bar, event) and if your function is only ever going to be called with the former (ie - any dom event handler) and you want the latter... it's absolutely useful.
I rather meant the interface between the partially applied foo and the version of foo that plucks bar from props when it's called.
Anyway, I see what you mean and it's a perfectly reasonable thing to do. Doesn't solve the original issue that was being discussed though :-)
Anyway, I see what you mean and it's a perfectly reasonable thing to do. Doesn't solve the original issue that was being discussed though :-)
> So all you have to do is use PureComponent everywhere and you’re good to go. There’s nothing more to it. Enjoy your new blazing fast React app!
(I work on React.) This isn't quite right. If we recommended that PureComponent be used everywhere, it would probably be the default already. Rather -- the comparison to decide whether or not a component should be rerendered costs something, and in the case that you do want to rerender, all of the time spent checking whether you should have rerendered is wasted.
Instead, we'd suggest you be conscious of where you need to do the comparisons. It's usually only in a couple of places in your app. Good candidates are on the children of a long list or around large parts of the app that change independently (that is, cases where you know the parent should often rerender but the child shouldn't). A few well-placed shouldComponentUpdate (or PureComponent) uses can go a long way.
(I work on React.) This isn't quite right. If we recommended that PureComponent be used everywhere, it would probably be the default already. Rather -- the comparison to decide whether or not a component should be rerendered costs something, and in the case that you do want to rerender, all of the time spent checking whether you should have rerendered is wasted.
Instead, we'd suggest you be conscious of where you need to do the comparisons. It's usually only in a couple of places in your app. Good candidates are on the children of a long list or around large parts of the app that change independently (that is, cases where you know the parent should often rerender but the child shouldn't). A few well-placed shouldComponentUpdate (or PureComponent) uses can go a long way.
Hi Ben! At the React conference, I asked Sebastian Markbåge (also a React author) why `PureComponent` wasn't the default and he said there were already too many new concepts when React was released, and it would have made adoption harder. But he implied that maybe it should be the default. (Then again, alcohol was involved so I could be misremembering.)
When using immutable data structures the comparison in `shouldComponentUpdate` is very cheap. Assuming that, using pure components everywhere is very tempting for simplicity.
Correct me if I'm wrong, but React creates an object for every component to pass props around. Constructing that object is linear in the number of props. An additional `shouldComponentUpdate` check for each component is also linear in the number of props. So using pure components everywhere is at worst adjusting the constant.
Also, in a world where PureComponent is the default, perhaps React could monitor the "hit rate" of `shouldComponentUpdate` and decide to not call it if a component returns true too often?
When using immutable data structures the comparison in `shouldComponentUpdate` is very cheap. Assuming that, using pure components everywhere is very tempting for simplicity.
Correct me if I'm wrong, but React creates an object for every component to pass props around. Constructing that object is linear in the number of props. An additional `shouldComponentUpdate` check for each component is also linear in the number of props. So using pure components everywhere is at worst adjusting the constant.
Also, in a world where PureComponent is the default, perhaps React could monitor the "hit rate" of `shouldComponentUpdate` and decide to not call it if a component returns true too often?
> When using immutable data structures the comparison in `shouldComponentUpdate` is very cheap. Assuming that, using pure components everywhere is very tempting for simplicity.
PureComponent always uses === on each prop value (regardless of type), so the comparison cost with PureComponent should be relatively flat regardless of whether you're using (persistent) immutable data structures. There's also a cost in looping over the prop values and indexing into the (megamorphic) hash map for each props object that is harder to quantify.
> React creates an object for every component to pass props around. Constructing that object is linear in the number of props. An additional `shouldComponentUpdate` check for each component is also linear in the number of props. So using pure components everywhere is at worst adjusting the constant.
That's true. We've just been a little wary of ending up in a "death by a thousand cuts" scenario where every single unnecessary PureComponent makes your app a little bit slower. A number of teams at Facebook have also chosen to use PureComponent for most use cases so you're not alone.
> Also, in a world where PureComponent is the default, perhaps React could monitor the "hit rate" of `shouldComponentUpdate` and decide to not call it if a component returns true too often?
That would be cool, doing a sort of "profile-guided optimization" for React trees. I don't think this would be feasible to give improvements at a per-user/per-session level but could potentially give significant wins if you had a way to collect stats across many different users.
PureComponent always uses === on each prop value (regardless of type), so the comparison cost with PureComponent should be relatively flat regardless of whether you're using (persistent) immutable data structures. There's also a cost in looping over the prop values and indexing into the (megamorphic) hash map for each props object that is harder to quantify.
> React creates an object for every component to pass props around. Constructing that object is linear in the number of props. An additional `shouldComponentUpdate` check for each component is also linear in the number of props. So using pure components everywhere is at worst adjusting the constant.
That's true. We've just been a little wary of ending up in a "death by a thousand cuts" scenario where every single unnecessary PureComponent makes your app a little bit slower. A number of teams at Facebook have also chosen to use PureComponent for most use cases so you're not alone.
> Also, in a world where PureComponent is the default, perhaps React could monitor the "hit rate" of `shouldComponentUpdate` and decide to not call it if a component returns true too often?
That would be cool, doing a sort of "profile-guided optimization" for React trees. I don't think this would be feasible to give improvements at a per-user/per-session level but could potentially give significant wins if you had a way to collect stats across many different users.
I've updated the post to say 'in the right places' instead of 'everywhere' until we get some profiling data.
> When using immutable data structures the comparison in `shouldComponentUpdate` is very cheap.
The equality check is always the same in pure components. Whether the data is immutable or not, pure components do a reference equality check. This will result in failing to update correctly with mutable data.
For simplicity, I guess you could go with PureComponent by default, and remove it as an optimization instead, which is what I've been doing with good results.
The equality check is always the same in pure components. Whether the data is immutable or not, pure components do a reference equality check. This will result in failing to update correctly with mutable data.
For simplicity, I guess you could go with PureComponent by default, and remove it as an optimization instead, which is what I've been doing with good results.
First off, thanks for your work on React! Makes all of our lives easier as developers :)
As dmnd pointed out, I'm not entirely convinced that dropping PureComponent everywhere is not a good idea.
For our app specifically, we unfortunately do data loading in a lot of places, which means that there are quite a bit more than just few places that can benefit from being a PureComponent. Our current idea is to try to make everything a PureComponent, and go back and 'unpurify' the places that have wasteful sCU comparisons. This might not turn out to be a good idea though, for the reasons you mentioned.
I'll make sure to do some profiling in our codebase once we get to that point, and see how much wasted sCU we are doing.
As dmnd pointed out, I'm not entirely convinced that dropping PureComponent everywhere is not a good idea.
For our app specifically, we unfortunately do data loading in a lot of places, which means that there are quite a bit more than just few places that can benefit from being a PureComponent. Our current idea is to try to make everything a PureComponent, and go back and 'unpurify' the places that have wasteful sCU comparisons. This might not turn out to be a good idea though, for the reasons you mentioned.
I'll make sure to do some profiling in our codebase once we get to that point, and see how much wasted sCU we are doing.
If the data structure is immutable, such that it's either a pointer comparison or "check until first part of the data is different", isn't it faster than render + diff anyway?
How do function(al?) components compare in performance to PureComponents?
e.g.,
e.g.,
const MyComponent = props => (...);
class MyComponent extends PureComponent {...}A functional component is not pure, it's exactly the same as its class counterpart. You can use recompose's[0] 'pure' HOC to turn it into a PureComponent.
[0] https://github.com/acdlite/recompose
[0] https://github.com/acdlite/recompose
I believe their question is asking about the trade-offs of a PureComponent, which is a Class and incurs a performance hit because of that versus a functional component which is always faster than the equivalent component written in a Class-y syntax.
I.e., do the gains from PureComponent exceed the cost of a Class? Personally I would assume they would otherwise no one would ever think of think using one, but it is an interesting question and set of metrics that could be gathered.
I.e., do the gains from PureComponent exceed the cost of a Class? Personally I would assume they would otherwise no one would ever think of think using one, but it is an interesting question and set of metrics that could be gathered.
Not sure I understand your question. Functional components and class components both use createClass internally IIRC. In any case, they are the same. A PureComponent is simply a Component with shouldComponentUpdate written for you. Functional components can't be pure, but you can use an enhancer for them.
Is it considered best practice to use the "key" of a child element to signify if it should rerender? This is what I've been doing and it seems to work well. If a parent updates its state, and then as a result, changes the props of some or all of its children, the parent sets the "key" of a child to effectively a hash of the props of that child.
I believe it's best practice to set the key to be something that is based on the identity of the component to be rendered.
The idea is that this is used to suggest whether when rendering a component, the children are new components, or simply existing components with updated props.
E.g. You have a component that renders a list of items. If you add an item, what you would rather do is create a single new child component and re-use the previously generated children vs. discarding the child components from a the previous render and creating a brand new set.
If you create a key based on a hash of the props this will decrease the time taken to re-render an set of child components with identical props, but at the cost of discarding an existing component and creating a new one if one of the props changes.
Or something like that.....
See for a bit more detail: https://facebook.github.io/react/docs/reconciliation.html
The idea is that this is used to suggest whether when rendering a component, the children are new components, or simply existing components with updated props.
E.g. You have a component that renders a list of items. If you add an item, what you would rather do is create a single new child component and re-use the previously generated children vs. discarding the child components from a the previous render and creating a brand new set.
If you create a key based on a hash of the props this will decrease the time taken to re-render an set of child components with identical props, but at the cost of discarding an existing component and creating a new one if one of the props changes.
Or something like that.....
See for a bit more detail: https://facebook.github.io/react/docs/reconciliation.html
I don't know the internal details but that sort of abuse of the key attribute seems like a dangerous thing to rely on.
I'll assume your key is quick to calculate. If a prop change causes the hash / key to change then react doesn't know how to reuse the dom fragment. I guess it will just reuse the stuff that's in the same location in that case so maybe it's fine. You'll lose the advantage that keys give you in the first case which is dealing with reordering.
And actually, just because the key changes or not, that doesn't cause a rerender or not. The rerender is always going to happen. Right? Unless I'm missing something.
I'll assume your key is quick to calculate. If a prop change causes the hash / key to change then react doesn't know how to reuse the dom fragment. I guess it will just reuse the stuff that's in the same location in that case so maybe it's fine. You'll lose the advantage that keys give you in the first case which is dealing with reordering.
And actually, just because the key changes or not, that doesn't cause a rerender or not. The rerender is always going to happen. Right? Unless I'm missing something.
keep in mind that changing the key will completely destroy and create a new element- a more expensive operation if all that's necessary is changing the class or something
nit: new component instance (not element)
I think we're both right- I believe it will create a new element and a new DOM element, rather than mutating the existing ones.
You're right. I misinterpreted your first comment to refer be referring to React elements, which is quite different from DOM elements
https://facebook.github.io/react/blog/2015/12/18/react-compo...
> If we recommended that PureComponent be used everywhere, it would probably be the default already.
> Instead, we'd suggest you be conscious of where you need to do the comparisons.
I'm not following, wouldn't that mean PureComponent by default and opt-in specialized checks when needed?
> Instead, we'd suggest you be conscious of where you need to do the comparisons.
I'm not following, wouldn't that mean PureComponent by default and opt-in specialized checks when needed?
No, because PureComponent does have a check.
His point is that you don't always need that check - that check has overhead too!
Basically PureComponent is just a specialized case of shouldComponentUpdate so it's better practice to be mindful of where you're calling that anyhow.
It's also why there's the push to use stateless functions (when you can) because the kind of pseudo micro-optimization that PureComponent actually is can have counter-intuitive consequences.
His point is that you don't always need that check - that check has overhead too!
Basically PureComponent is just a specialized case of shouldComponentUpdate so it's better practice to be mindful of where you're calling that anyhow.
It's also why there's the push to use stateless functions (when you can) because the kind of pseudo micro-optimization that PureComponent actually is can have counter-intuitive consequences.
Hey Ben! Could you speak to using stateless functional components vs PureComponent in terms of performance, especially now that Fiber is close? Which one would you use today?
how expensive are shallow === checks compared to re-rendering unnecessarily though? what advantages would stateless functional components offer above purecomponents?
If your check returned true, you'll re-render anyway, so time for this check is effectively wasted. Imagine that every check returns true. It's better to avoid this check at all in that component.
to clarify, i meant stateless functional components after they've been optimized in React 16
Literally the next section is "*Except…", so might want to continue reading the article before leaving your comment here
Hi! I did read the whole article and don't believe it addresses the point that I called out in my comment. I hope you'll agree after reading the article and my comment carefully.
I would generally say that there is a reciprocal relationship of performance and maintainable code, no matter what you use.
React is a powerful way to build your front-end, but it's power is in structure / code.
In my experience with React, fine-tuning components for faster rendering is always a pain. Too much magic happens behind the scenes and too difficult to keep that in mind while writing your beautiful components.
React is a powerful way to build your front-end, but it's power is in structure / code.
In my experience with React, fine-tuning components for faster rendering is always a pain. Too much magic happens behind the scenes and too difficult to keep that in mind while writing your beautiful components.
there is a reciprocal relationship of performance and maintainable code
There isn't an inherent one, it's just that writing for both is much harder than just for one.
There isn't an inherent one, it's just that writing for both is much harder than just for one.
I am more concerned that the code that runs during a re-render is not rebuilding huge static lists that never change and so. I see that over and over again in React apps. I tend to build a lot of the static stuff in the ComponentWillMount stage to prevent that. Only when already optimised code is getting to slow I start thinking about preventing re-rendering if possible.
My reason for not starting with ShouldComponentUpdate is that you have to be very careful not creating nasty bugs with that like I did some times. If a year later you write some code and it doesn't work for some reason it is painful if you find out after a long search that a stupid child component did not update for some prevention rule you forgot about. I really try hard to avoid premature optimisations.