-
Notifications
You must be signed in to change notification settings - Fork 46.9k
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
Don't define key or ref dummy props if none were provided #7488
Conversation
This fixes a performance regression.
displayName | ||
); | ||
} | ||
return undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it useful to return undefined;
as the last line of a function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copypasta. Not sure why it was there. Removing.
Seems fine. I wonder if it makes more sense to put these on a prototype and have the props object extend from there. That would subtly change some semantics though so maybe this is better. |
* Don't define key or ref dummy props if none were provided This fixes a performance regression. * Style nit (cherry picked from commit a56e105)
My unit tests for react-isomorphic-form are failing since this change. I see that apparently I'm not supposed to be using class Input extends React.Component {
constructor(props) {
super(props)
this.ref = this.ref.bind(this)
}
ref(el) {
// do stuff
this.props.ref(el)
}
render() {
return <input {...this.props} ref={this.ref} />
}
} Full source: https://github.com/ghengeveld/react-isomorphic-form/blob/master/src/Input.js I think dealing with ref that way makes perfect sense and allows for a more predictable API. I'm trying to create a component that is a very thin wrapper around a native HTML component, so I don't want to use custom prop names. Perhaps I should switch to higher-order components but I'm not sure that would provide a nicer or clearer API. Suggestions are welcome. |
this.props.ref will always be undefined for you, so your example does not work as you intend. #4213 tracks supporting your use case. |
This worked fine in 15.3.0. For now I'll just remove the ability to pass through |
It worked fine by accident because we defined a dummy If you are sure it’s our mistake please provide a jsfiddle showing the problem. |
This fixes another DEV-only performance regression introduced in 15.x.
The idea here is that extra
defineProperty
getters are slow. Let’s only add them when we know user suppliedkey
(orref
). Otherwise the user wouldn’t expect to find them inprops
anyway.Chrome (before):
Chrome (after):
Firefox (before):
Firefox (after):
I’m too lazy to format Safari results but they show similar improvements although smaller.