Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maybe ref attribute usage could cause performance problem? #9086

Closed
NE-SmallTown opened this issue Mar 1, 2017 · 6 comments
Closed

Maybe ref attribute usage could cause performance problem? #9086

NE-SmallTown opened this issue Mar 1, 2017 · 6 comments

Comments

@NE-SmallTown
Copy link
Contributor

NE-SmallTown commented Mar 1, 2017

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.

@NE-SmallTown NE-SmallTown changed the title Maybe ref attribute usage maybe could cause performance problem? Maybe ref attribute usage could cause performance problem? Mar 1, 2017
@gaearon
Copy link
Collaborator

gaearon commented Mar 1, 2017

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 gaearon closed this as completed Mar 1, 2017
@NE-SmallTown
Copy link
Contributor Author

NE-SmallTown commented Mar 1, 2017

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

@gaearon
Copy link
Collaborator

gaearon commented Mar 1, 2017

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.

@NE-SmallTown
Copy link
Contributor Author

@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!

@gaearon
Copy link
Collaborator

gaearon commented Mar 1, 2017

Haha no worries 😄
Happy to chat about this.

@mvasin
Copy link

mvasin commented Jul 9, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants