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

[Docs] [Question] Refs - Callback vs String #6250

Closed
hnordt opened this issue Mar 11, 2016 · 3 comments
Closed

[Docs] [Question] Refs - Callback vs String #6250

hnordt opened this issue Mar 11, 2016 · 3 comments

Comments

@hnordt
Copy link
Contributor

hnordt commented Mar 11, 2016

I was reading the docs again, it's not clear to me the difference between defining a ref as a callback vs string:

<input ref={input => this._input = input} /> vs <input ref="input" />

Can someone clarify to me please?

@gaearon
Copy link
Collaborator

gaearon commented Mar 11, 2016

If you define ref as a string, it will be available on this.refs object, for example, this.refs.input.
If you define a callback ref, you are free to do anything with it, including saving it on this if you’d like.

The string refs are eventually going to be deprecated. Callback refs were introduced later but they cover all use cases of string refs and don’t have some of their downsides. I suggest you to always use callback refs in the new code you write.

In the future, please consider asking questions on StackOverflow. We don’t officially consider issue tracker to be a support forum, and unfortunately GitHub search does not work as well as StackOverflow search, so it’s likely somebody is going to ask this again. Whereas if you posted this on StackOverflow, it’s likely you’d get a good answer, your question would get voted up, and more people would have learned from it and found it in the future.

@gaearon gaearon closed this as completed Mar 11, 2016
@hnordt
Copy link
Contributor Author

hnordt commented Mar 11, 2016

Thank you again @gaearon. I'll use StackOverflow next time.

@gaearon
Copy link
Collaborator

gaearon commented Mar 11, 2016

No problem! Please feel free to submit a pull request to the documentation if you feel like we could make it more obvious that we recommend the callback ref pattern in the new code.

jchip pushed a commit to electrodejs/deprecated-electrode-archetype-react-app that referenced this issue Aug 16, 2016

string refs are considered legacy and the callback approach is the recommended way forward.
https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/no-string-refs.md

String refs will eventually go away in React core.
facebook/react#4174
facebook/react#6350
facebook/react#6250

ReactCurrentOwner is the only remaining piece of shared global state in React internals. String refs are the primary reason it is still around.

The benefit of adopting this now (pre-deprecation) is to be ahead of the curve when that does happen.
jchip pushed a commit to jchip/electrode-archetype-react-component that referenced this issue Dec 15, 2016
string refs are considered legacy and the callback approach is the recommended way forward.
https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/no-string-refs.md

String refs will eventually go away in React core.
facebook/react#4174
facebook/react#6350
facebook/react#6250

ReactCurrentOwner is the only remaining piece of shared global state in React internals. String refs are the primary reason it is still around.

The benefit of adopting this now (pre-deprecation) is to be ahead of the curve when that does happen.
jchip pushed a commit to electrode-io/electrode that referenced this issue Dec 15, 2016
string refs are considered legacy and the callback approach is the recommended way forward.
https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/no-string-refs.md

String refs will eventually go away in React core.
facebook/react#4174
facebook/react#6350
facebook/react#6250

ReactCurrentOwner is the only remaining piece of shared global state in React internals. String refs are the primary reason it is still around.

The benefit of adopting this now (pre-deprecation) is to be ahead of the curve when that does happen.
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

2 participants