Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Optimizing React Rendering

flexport.engineering

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Optimizing React Rendering

#61

Post by aidos »

abritinthebay wrote: post #53
aidos wrote: post #46

Earlier quoted context omitted.

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…

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.

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

Re: Optimizing React Rendering

#62

Post by joncrocks »

chatmasta wrote: post #18
sophiebits wrote: post #11

> 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…

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

Re: Optimizing React Rendering

#63

Post by evan_ »

dounan wrote: post #29
evan_ wrote: post #28

Earlier quoted context omitted.

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.

Re: Optimizing React Rendering

#64

Post by sophiebits »

dmnd wrote: post #15
sophiebits wrote: post #11

> 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…

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 `shouldCo…

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

Re: Optimizing React Rendering

#65

Post by anotherfounder »

sophiebits wrote: post #11

> 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…

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?

Re: Optimizing React Rendering

#66

Post by dounan »

sophiebits wrote: post #64
dmnd wrote: post #15

Earlier quoted context omitted.

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 `shouldCo…

> 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 loopin…

I've updated the post to say 'in the right places' instead of 'everywhere' until we get some profiling data.

Re: Optimizing React Rendering

#67

Post by dounan »

uranian wrote: post #48

For some reason the focus is always on preventing re-rendering if it comes to optimising a React app. I understand that it can be really effective and is often the easy way out, but re-rendering in itself is not costly and I don't really care about it the most of the time. 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 o…

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

Re: Optimizing React Rendering

#68

Post by dounan »

doctorcroc wrote: post #38
dounan wrote: post #25

Earlier quoted context omitted.

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

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 ( ); Then your onClick in the…

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

Re: Optimizing React Rendering

#69

Post by korm »

doytch wrote: post #60
korm wrote: post #49

Earlier quoted context omitted.

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

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…

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.

Re: Optimizing React Rendering

#70

Post by devopsproject »

seattle_spring wrote: post #57
devopsproject wrote: post #47

Earlier quoted context omitted.

The downvotes are sad. Are people this far gone that they can't take a little criticism?

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?
Post reply on HN