Don't define key or ref dummy props if none were provided

[gaearon]

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 supplied key (or ref). Otherwise the user wouldn’t expect to find them in props anyway.

Chrome (before):

create 10k rows: 6596
update 1k rows: 1447
update 1k rows: 1362
update 1k rows: 1385
clear 10k rows: 1094

create 10k rows: 6403
update 1k rows: 1428
update 1k rows: 1321
update 1k rows: 1393
clear 10k rows: 1182

Chrome (after):

create 10k rows: 5373
update 1k rows: 1294
update 1k rows: 1313
update 1k rows: 1246
clear 10k rows: 1060

create 10k rows: 5446
update 1k rows: 1326
update 1k rows: 1233
update 1k rows: 1268
clear 10k rows: 1102

Firefox (before):

create 10k rows: 10431
update 1k rows: 1664
update 1k rows: 896
update 1k rows: 853
clear 10k rows: 4157

create 10k rows: 10044
update 1k rows: 1091
update 1k rows: 1197
update 1k rows: 847
clear 10k rows: 3225

Firefox (after):

create 10k rows: 8241
update 1k rows: 858
update 1k rows: 715
update 1k rows: 725
clear 10k rows: 3877

create 10k rows: 8200
update 1k rows: 831
update 1k rows: 775
update 1k rows: 720
clear 10k rows: 4239

I’m too lazy to format Safari results but they show similar improvements although smaller.

[vjeux]

is it useful to return undefined; as the last line of a function?

[gaearon]

Copypasta. Not sure why it was there. Removing.

[sophiebits]

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.

[ghengeveld]

My unit tests for react-isomorphic-form are failing since this change. I see that apparently I'm not supposed to be using this.props.ref, but I am. Bare example:

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.

[sophiebits]

this.props.ref will always be undefined for you, so your example does not work as you intend. #4213 tracks supporting your use case.

[ghengeveld]

This worked fine in 15.3.0. For now I'll just remove the ability to pass through ref as a prop, awaiting #4213.

[gaearon]

It worked fine by accident because we defined a dummy ref prop in development that just printed a warning. It was never part of public API and not mean to be supported.

If you are sure it’s our mistake please provide a jsfiddle showing the problem.