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

Add else block to setSelectionRange check #373

Merged
merged 1 commit into from Jun 21, 2020
Merged

Add else block to setSelectionRange check #373

merged 1 commit into from Jun 21, 2020

Conversation

WretchedDade
Copy link
Contributor

What:
This fixes #369

Why:
Without this change, when a value is changed programatically as part of a React onChange event, the selectionRange stays at (0, 0) causing the values to be typed in reverse order.

How:
Added an else block to the setSelectionRange function that is part of type. The conditional already existed to check to see if the value changed programatically and my else adds logic to move the selection range to the end of the input to mimic the behavior of the browser.

Checklist:

  • Documentation (N/A)
  • Tests
  • Typings (N/A)
  • Ready to be merged

I attempted to replicate my failing react testing here by using the same format function and setting event.target.value when the input event fired. However, the test passed without my change. This leads me to believe that it is a symptom of how the value of an input is controlled by React. To confirm this fixed my issue I had to do the following:

  1. npm run build
  2. Copy the contents of dist/type.js to my React project's node_modules/@testing-library/user-event/dist/type.js file.

@codecov
Copy link

codecov bot commented Jun 21, 2020

Codecov Report

Merging #373 into master will not change coverage.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff            @@
##            master      #373   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           12        12           
  Lines          376       383    +7     
  Branches       109       111    +2     
=========================================
+ Hits           376       383    +7     
Impacted Files Coverage Δ
src/type.js 100.00% <100.00%> (ø)
src/tab.js 100.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f4eae9c...e6261e0. Read the comment docs.

Copy link
Member

@nickmccurdy nickmccurdy left a comment

Choose a reason for hiding this comment

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

Ideally it would be nice to figure out a way to reproduce in a test, but it sounds fairly difficult without coupling our tests to React again, so I'm fine with this.

Copy link
Member

@kentcdodds kentcdodds left a comment

Choose a reason for hiding this comment

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

This makes sense to me 👍 thanks!

@kentcdodds kentcdodds merged commit 5c9257b into testing-library:master Jun 21, 2020
@kentcdodds
Copy link
Member

@all-contributors please add @WretchedDade for code and tests

@allcontributors
Copy link
Contributor

@kentcdodds

I've put up a pull request to add @WretchedDade! 🎉

@kentcdodds
Copy link
Member

🎉 This PR is included in version 12.0.4 🎉

The release is available on:

Your semantic-release bot 📦🚀

@WretchedDade
Copy link
Contributor Author

Awesome! Thanks ya'll!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

userEvent.type doesn't work well when a value is formatted after the onChange is fired
3 participants