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

21–30 of 79 posts

Re: Optimizing React Rendering

#21

Post by spicyj »

diggan wrote: post #14
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…

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.

Re: Optimizing React Rendering

#22

Post by drinchev »

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.

Re: Optimizing React Rendering

#23

Post by continuational »

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…

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?

Re: Optimizing React Rendering

#24

Post by dounan »

zevyoura wrote: post #20
positivecomment wrote: post #10

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 }); } handleDelete(index) { //... } I guess they just call that function from within the Data component with the correct parameter. But then, Data component needs to know how to call that functi…

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.

Re: Optimizing React Rendering

#25

Post by dounan »

positivecomment wrote: post #10

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 }); } handleDelete(index) { //... } I guess they just call that function from within the Data component with the correct parameter. But then, Data component needs to know how to call that functi…

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

Re: Optimizing React Rendering

#26

Post by pvg »

drinchev wrote: post #22

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

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.

Re: Optimizing React Rendering

#28

Post by evan_ »

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.

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

Re: Optimizing React Rendering

#29

Post by dounan »

evan_ wrote: post #28
chatmasta wrote: post #18

Earlier quoted context omitted.

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.

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