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

fix TextArea inputRef update event #4198

Merged
merged 1 commit into from
Jun 29, 2020

Conversation

Arbalester
Copy link
Contributor

Fixes #4072

Checklist

  • Includes tests
  • Update documentation

Changes proposed in this pull request:

TextArea should call updated inputRef prop with the current DOM element.

@palantirtech
Copy link
Member

Thanks for your interest in palantir/blueprint, @Arbalester! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.

Copy link
Contributor

@adidahiya adidahiya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @Arbalester

@adidahiya adidahiya merged commit 35aa353 into palantir:develop Jun 29, 2020
Copy link

@trixn86 trixn86 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Arbalester

Why are the inputRefs compared as their string representations (prevProps.inputRef.toString() !== this.props.inputRef.toString()) and not simply by reference equality? Is this intended to prevent it from updating when the user did not correctly memorize the callback? Feels like a hack to be honest. And it is also not be the behaviour one would expect. Reacts built-in elements handle that differently (https://codesandbox.io/s/thirsty-panini-oc3uu?file=/src/App.js).In my opinion the developer using the ref is responsible for correctly memorizing his/her ref callbacks. If I wanted to console.log the ref on every render cycle I couldn't do it just because the code of my function stays the same even when it's a new function.

Any even more problematic: If you pass a ref created by the useRef() hook, it will always be equal as it's an object whose string representation is simply [object Object].

@Arbalester
Copy link
Contributor Author

@Arbalester

Why are the inputRefs compared as their string representations (prevProps.inputRef.toString() !== this.props.inputRef.toString()) and not simply by reference equality? Is this intended to prevent it from updating when the user did not correctly memorize the callback? Feels like a hack to be honest. And it is also not be the behaviour one would expect. Reacts built-in elements handle that differently (https://codesandbox.io/s/thirsty-panini-oc3uu?file=/src/App.js).In my opinion the developer using the ref is responsible for correctly memorizing his/her ref callbacks. If I wanted to console.log the ref on every render cycle I couldn't do it just because the code of my function stays the same even when it's a new function.

Any even more problematic: If you pass a ref created by the useRef() hook, it will always be equal as it's an object whose string representation is simply [object Object].

Yeah, my bad. Made a fix for this.

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

Successfully merging this pull request may close these issues.

TextArea does not call updated inputRef prop
4 participants