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

11–20 of 79 posts

Re: Optimizing React Rendering

#11

Post by sophiebits »

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

Re: Optimizing React Rendering

#12

Post by [deleted] »

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…

[deleted]

Re: Optimizing React Rendering

#14

Post by diggan »

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

Re: Optimizing React Rendering

#15

Post by dmnd »

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 `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?

Re: Optimizing React Rendering

#16

Post by kentor »

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…

Nope. For dom elemenets I have been using `data-{name}` attributes, and pulling them out from the handler using `e.currentTarget.dataset.{name}`

Re: Optimizing React Rendering

#17

Post by o_____________o »

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

Re: Optimizing React Rendering

#18

Post by chatmasta »

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.

Re: Optimizing React Rendering

#19

Post by nip »

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…

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/

Re: Optimizing React Rendering

#20

Post by zevyoura »

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