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 support for arrowdown and arrowup events #503

Closed
corymharper opened this issue Nov 25, 2020 · 9 comments · Fixed by #511
Closed

Add support for arrowdown and arrowup events #503

corymharper opened this issue Nov 25, 2020 · 9 comments · Fixed by #511
Labels

Comments

@corymharper
Copy link
Contributor

  • Testing-library/user-event` version: 12.2.2
  • Testing Framework and version: jest/26.0.15
  • DOM Environment: react-dom/17.0.0

What you did:

I have a module I'm migrating from Enzyme over to testing-library, the module is a React hook that for the most part manages keyboard controls to follow accessibility guidelines for dropdown menus. Part of our tests simulate arrowdown and arrowup events while focused on list items to ensure the correct resulting focused element is obtained. We ran into this issue while trying to replicate that behavior using userEvent.

What happened:

userEvent.type only supports ArrowLeft and ArrowRight keys.

Problem description:

While trying to implement tests to replace Enzyme with testing-library we were attempting to use userEvent instead of fireEvent where ever possible, as suggested by the documentation. However, we are currently unable to replicate tests that used ArrowDown and ArrowUp as that's just not one of the special characters supported by userEvent.type.

Suggested solution:

Add ArrowDown and ArrowUp as supported special keys for userEvent.type. Also, while reading over the documentation and through some issues, the documentation for userEvent.type seems off the mark for the variety of purposes it is used for now:

Writes text inside an or a <textarea>.

This should probably be modified to indicate that it's used with a variety of types of elements now, or a new method could be added to userEvent meant for these situations were you aren't necessarily "typing".

@nickmccurdy
Copy link
Member

It would be difficult to implement this consistently for textareas: #404 (comment)

You mentioned adding other events, that might work better in this case. What exactly are arrowdown and arrowup doing in your component? Is this an accessibility feature to quickly read multiple items in a list, or is this part of a select?

@corymharper
Copy link
Contributor Author

corymharper commented Nov 29, 2020

It would be difficult to implement this consistently for textareas: #404 (comment)

You mentioned adding other events, that might work better in this case. What exactly are arrowdown and arrowup doing in your component? Is this an accessibility feature to quickly read multiple items in a list, or is this part of a select?

Specifically I am working with a React hook that manages focus to meet accessibility standards for dropdown menus. In the scope of that, arrow up and down moves focus between menu items, very similarly to how a select menu might work but with a variety of elements (Think like a group of <li>).

Just for example's sake here is the demo.

@kentcdodds
Copy link
Member

This is a good point. We should add support for this situation. Maybe for textarea/input it could just go to the start/end of the input

@corymharper
Copy link
Contributor Author

This is a good point. We should add support for this situation. Maybe for textarea/input it could just go to the start/end of the input

Okay, so you're suggesting that it would be an extension of the behavior of userEvent.type if I understand correctly, and not an additional type of event.

@kentcdodds
Copy link
Member

Correct. It would be used like so: userEvent.type(el, '{arrowup}{arrowdown}')

@corymharper
Copy link
Contributor Author

Do you believe the concern you mentioned in the comment by @nickmccurdy is still something of a concern for the implementation, or is an expecation that it will go to the beginning or end of the input enough?

@corymharper
Copy link
Contributor Author

And if you would like, I'm more than willing to pick up the work for this refactoring.

@kentcdodds
Copy link
Member

Actually, I'm thinking we should probably only fire the events, and not change the selection range. And you're more than welcome to give this a go :)

@github-actions
Copy link

github-actions bot commented Dec 3, 2020

🎉 This issue has been resolved in version 12.5.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

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 a pull request may close this issue.

3 participants