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

71–79 of 79 posts

Re: Optimizing React Rendering

#71

Post by ma_long_bay »

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…

how expensive are shallow === checks compared to re-rendering unnecessarily though? what advantages would stateless functional components offer above purecomponents?

Re: Optimizing React Rendering

#72

Post by dounan »

evan_ wrote: post #63
dounan wrote: post #29

Earlier quoted context omitted.

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

Re: Optimizing React Rendering

#73

Post by ma_long_bay »

ma_long_bay wrote: post #71
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…

how expensive are shallow === checks compared to re-rendering unnecessarily though? what advantages would stateless functional components offer above purecomponents?

to clarify, i meant stateless functional components after they've been optimized in React 16

Re: Optimizing React Rendering

#74

Post by joncampbelldev »

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

Re: Optimizing React Rendering

#75

Post by joncampbelldev »

joncampbelldev wrote: post #74

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

Re: Optimizing React Rendering

#76

Post by vbezhenar »

ma_long_bay wrote: post #71
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…

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.

Re: Optimizing React Rendering

#77

Post by bobsam »

seattle_spring wrote: post #56
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 :(

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?

Re: Optimizing React Rendering

#78

Post by bobsam »

e1g wrote: post #55
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?

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…

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

Re: Optimizing React Rendering

#79

Post by seangrogg »

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…

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

Post reply on HN