Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact cla@fb.com if you have any questions.

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

Hmm, this sentence doesn't quite make sense to me. For every render, React calls the ref callback twice? Not on the first render, right? And what is the function instance exactly that this sentence refers to?

Rough concept:

When react diffs the virtual dom, if the ref prop is not strictly equal (===) to the previous ref callback, it will call the previous ref callback with null before calling the new callback with the dom element. When the component unmounts, the ref callback will be called with null. This allows you to do clean up work, similar to componentWillUnmount.

Maybe some mention of defining ref callbacks in constructor or using the public class fields proposal.

So the right takeaway is basically, you should only use ref callbacks with the ref={(foo) => this.foo = foo} pattern. If you do that, you don't need to worry, you'll just get some weirdo nulls sometimes but whatever. If you don't do that, then you are asking for trouble.

Thanks for the PR. Closing as the author did not respond to review, but happy to reopen if you'd like to reword it as suggested!

@lacker @gaearon

So the right takeaway is basically, you should only use ref callbacks with the ref={(foo) => this.foo = foo} pattern. If you do that, you don't need to worry, you'll just get some weirdo nulls sometimes but whatever. If you don't do that, then you are asking for trouble.

If, we MUST using only this pattern, then it is redundant, because It is much easier to use the ref = "foo" pattern.

In other side, ref-function, allows write link to component with different model, e.g. in observable object. And in this case, it would be nice to know about the "extra" ref calls (for debounce save method or debounce listeners of that observable object)

Also I think in situation where described cases when ref calls, most developers thinks that ONLY this cases exists.

If, we MUST using only this pattern, then it is redundant, because It is much easier to use the ref = "foo" pattern.

Being "easier" does not make it right, ref="foo" is a flawed pattern, there are important technical differences between the two. The problem here really is the clunky syntax (ref={(c) => this.foo = c}). If it was just ref={=this.foo} then it would be a non-issue. So that means it's a language/syntax problem and not an API problem, but if someone is using refs and this pattern enough to be significantly bothered by it then it probably indicates a misunderstanding or misuse of React.

ref="foo" is a flawed pattern, there are important technical differences between the two.

Hmm.. I thought it was just shortcut for ref={(c) => this.refs.componentName = c}, why it is flawed? What differences make it so?

There are multiple problems with it:

• It requires that React keeps track of currently rendering component (since it can't guess this). This makes React a bit slower.
• It doesn't work as most people would expect with the "render callback" pattern (e.g. <DataGrid renderRow={this.renderRow} />) because the ref would get placed on DataGrid for the above reason.
• It is not composable, i.e. if a library puts a ref on the passed child, the user can't put another ref on it (e.g. Any better way to get refs in ReactTransitionGroup? #8734). Callback refs are perfectly composable.

It doesn't work as most people would expect with the "render callback" pattern (e.g. <DataGrid renderRow={this.renderRow} />) because the ref would get placed on DataGrid for the above reason.

@gaearon Could you please elaborate more, what's the ref declaration and use in your example?

@gaearon Is there any reason to avoid callback refs like ref={c => this.refs.componentName = c}?

The current documentation seems to suggest this.refs should be avoided completely, linking to your above comment against string refs as it's justification.

@aij I guess because this.refs is reserved for different api (string refs).

@VladislavBaranov String refs will be deprecated in 16.4. 16.3 will be released with new createRef api, so I don't recommend to rely on string refs anymore.

Why not keep string refs as a syntatic sugar for ref={c => this.refs[stringRef]= c} applied during compilation?

String refs are far more readable than callback refs and react could use more readability oriented features.

I hope I'm not the only one who disagree with the reasons to remove string refs. They are a good feature, if anyone knows the reasons in more depth please comment on this issue I've just created: #15559

class MyComponent extends Component {
  renderRow = (index) => {
    // This won't work. Ref will get attached to DataTable rather than MyComponent:
    return <input ref={'input-' + index} />;

    // This would work though! Callback refs are awesome.
    return <input ref={input => this['input-' + index] = input} />;
  }
 
  render() {
    return <DataTable data={this.props.data} renderRow={this.renderRow} />
  }
}

Couldn't you just:

this.inputs[index] = <input />;

(New to React and still learning so sorry if I'm ignorant of something here)

wewe