-
Notifications
You must be signed in to change notification settings - Fork 249
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
feat: focus trap on tab #193
feat: focus trap on tab #193
Conversation
Codecov Report
@@ Coverage Diff @@
## master #193 +/- ##
=======================================
Coverage 97.05% 97.05%
=======================================
Files 1 1
Lines 136 136
Branches 35 35
=======================================
Hits 132 132
Misses 4 4
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Looks good. Just wondering about the use case and implications.
Options: | ||
|
||
- `shift` (default `false`) can be true or false to invert tab direction. | ||
- `focusTrap` (default `document`) a container element to restrict the tabbing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the motivation here? Doesn't this create a test user scenario?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kentcdodds so let me start with the motivation for a focus trap option. We are using focus-trap-react which keeps tabbing confined within an element. Because jsdom doesn't have any way to deal with tabbing, these types of components won't work in jsdom.
So since jsdom doesn't seem to support tabs yet, focus trap basically won't work with userEvent.tab(). So does this introduce a test user? Maybe. But my hope is that jsDom can add support for tab and this entire feature can basically just adopt that. In the meantime this seems like the least bad option. That said if you have another way of writing a test that can let the user tab through a focus trap, I'd love to get some better ideas.
Here's the code for focus-trap which ftR uses under the hood.
https://github.com/davidtheclark/focus-trap/blob/master/index.js
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense. I would add a note about the original intent for the option and why it should be used sparingly.
Then you've got a 👍 from me :) Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do! Thx Kent!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Gpx any chance you can merge this? we could really use it. :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like @Gpx is currently unavailable, so I'll go ahead and merge this. Thanks!
Vue tests are missing 🙈 no problem though, I guess I can work on them even after merging! 😄 |
I'm kinda thinking we should just ditch the framework specific stuff and use raw DOM stuff like in DOM Testing Library. |
🎉 This PR is included in version 7.2.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Fully agree 👍 |
Yeah, makes sense. |
This feature allows you to easily test tabbing in focus traps.
example:
userEvent.tab({focusTrap: containerElement})
also adds tab to readme and converts expects to use jest dom for tabs