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

51–60 of 79 posts

Re: Optimizing React Rendering

#51

Post by dounan »

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…

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.

Re: Optimizing React Rendering

#52

Post by dounan »

ChrisCinelli wrote: post #50

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

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

Re: Optimizing React Rendering

#53

Post by abritinthebay »

aidos wrote: post #46
abritinthebay wrote: post #43

Earlier quoted context omitted.

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.

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.

Re: Optimizing React Rendering

#54

Post by korm »

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.

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.

Re: Optimizing React Rendering

#55

Post by e1g »

devopsproject wrote: post #47
bobsam wrote: post #3

Earlier quoted context omitted.

so basically the Facebook app team? Edit: sorry guys, didn't knew you were all on HN :(

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.

Re: Optimizing React Rendering

#56

Post by seattle_spring »

bobsam wrote: post #3
mercer wrote: post #2

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

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.

Re: Optimizing React Rendering

#57

Post by seattle_spring »

devopsproject wrote: post #47
bobsam wrote: post #3

Earlier quoted context omitted.

so basically the Facebook app team? Edit: sorry guys, didn't knew you were all on HN :(

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.

Re: Optimizing React Rendering

#58

Post by azundo »

Silhouette wrote: post #39
nip wrote: post #19

Earlier quoted context omitted.

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/

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

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.

Re: Optimizing React Rendering

#59

Post by mstijak »

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

Re: Optimizing React Rendering

#60

Post by doytch »

korm wrote: post #49
rhinoceraptor wrote: post #37

Earlier quoted context omitted.

How do function(al?) components compare in performance to PureComponents? e.g., const MyComponent = props => (...); vs 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

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.

Post reply on HN