-
-
Notifications
You must be signed in to change notification settings - Fork 32.4k
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
[test] Use actual element over document.activeElement #20945
[test] Use actual element over document.activeElement #20945
Conversation
Details of bundle changes.Comparing: 8f8294d...8042cac Details of page changes
|
I was wondering about it at some point, I liked how using document.activeElement fits closer to real-life usage. We get the guarantee that if an event moves the active element, we stay on the new element but don't like that we don't really know "where we are". No preference, it feels equality ok. Maybe there is an opportunity for a |
I think in almost all cases you shouldn't use |
if (target !== element) { | ||
// see https://www.w3.org/TR/uievents/#keyup | ||
const error = new Error( | ||
`\`keyup\` events can only be targeted at the active element which is ${prettyDOM( |
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.
Pretty cool. Should the logic move to testing-library later on?
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.
Was gonna suggest/ask the same actually 🙂
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.
I think most people wanted to do this in user-event but also with automatically focusing. I think this is fine for app-tests but for component-tests we want to have a bit more control. Basically be as explicit as possible (fire keyDown, keyUp rather than user-event.keypress) but catch non-sensical dispatches such as fireEvent.keyDown(<section />)
.
While it's definitely a good idea to make sure the keyboard event target is the active element, it hurts readability in many cases. It's oftentimes not immediately clear what element is currently focused.
We now lint against
fireEvent.key*(document.activeElement)
while also ensuring that the target is focused. If it's not we throw and include the currently focused element.