React: Maybe ref attribute usage could cause performance problem?

Created on 1 Mar 2017  Â·  6Comments  Â·  Source: facebook/react

In the doc of ref attribute:

return (
    <div>
      <input
        type="text"
        ref={(input) => { this.textInput = input; }} />
    </div>
);

I thinks it maybe cause performance problem just as the arrow function of event bind in handle event

render() {
  // This syntax ensures `this` is bound within handleClick
  return (
    <button onClick={(e) => this.handleClick(e)}>
      Click me
    </button>
  ); 
}

the doc mention the performance problem at below:

The problem with this syntax is that a different callback is created each time the LoggingButton renders. 
In most cases, this is fine. However, if this callback is passed as a prop to lower components, those 
components **might do an extra re-rendering**. We generally recommend binding in the constructor or 
using the property initializer syntax, to avoid this sort of performance problem.

But in the ref attribute section,there are no tips.

So I want to know your thoughts on this.Thanks.

Most helpful comment

Most of the problems with arrows in events are because the prevent shallow comparison optimizations in components below with PureComponent. This doesn’t affect refs because they are not part of the props.

Creating a new function per se is not that expensive in modern engines, and makes very little difference aside from few very perf-sensitive cases. There is some extra work React needs to do to detach and attach ref when the function changes, but I wouldn’t worry about it.

If you’re just worrying “what if this makes my app slow”, no, it won’t. There are dozens of other things that can slow down your app which will matter more than this. If, however, you determined that specifically this is a problem by profiling your app, sure, not using an arrow here may help you.

All 6 comments

Most of the problems with arrows in events are because the prevent shallow comparison optimizations in components below with PureComponent. This doesn’t affect refs because they are not part of the props.

Creating a new function per se is not that expensive in modern engines, and makes very little difference aside from few very perf-sensitive cases. There is some extra work React needs to do to detach and attach ref when the function changes, but I wouldn’t worry about it.

If you’re just worrying “what if this makes my app slow”, no, it won’t. There are dozens of other things that can slow down your app which will matter more than this. If, however, you determined that specifically this is a problem by profiling your app, sure, not using an arrow here may help you.

@gaearon Thanks dan,sorry,I forget that "refs are not part of the props".But this make me consider another question,what attributes are not part of the props except refs?

And last question:

Few days ago,I notice that the React.PureComponent src code doesn't implement the compare function(I mean if(state !== next.state && props !== next.props) return false like PureRenderMixin(I know it wii be deprecated soon)),but I know it does implement it,I just don't know how to find the src code,could you tell me?Thanks.

But this make me consider another question,what attributes are not part of the props except refs?

key and ref.

I just don't know how to find the src code,could you tell me?

Yea, it just sets a flag that React reads. Current React version implements it here. Next React version has this check here. Note that the flag itself is not a public API, and may change in the future.

@gaearon Thanks!

Finally,the reason of post this issue is just I forget that "refs are not part of the props", I don't mean "Creating a new function per se is expensive in modern engines", I read your a lot of your twiiter,and I know that you explain many times about performance,hope that this issue will not make you plaint "oh god,again,I say many times that the function call,create objects....are not the key of performance of project,but this issue still misunderstand the performance".Have a good day!

Haha no worries 😄
Happy to chat about this.

I guess the biggest performance hit would be doing any stuff with ref element that causes layout reflow in a browser. And that's pretty much most of the stuff you would want to access a ref element for.

Was this page helpful?
0 / 5 - 0 ratings