You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, it is impossible to test hover states with JavaScript. One common solution for this is to use a special class for hovered elements instead of the pseudo-class :hover.
In storybook, there is an addon for this. There's also one (which I use) for postcss, which is great: replaces :hover in CSS with .\:hover, so the hover states is activated with class=":hover" instead of a real hover.
Note that this works with all pseudo-states, not just hover. The issue is that it is difficult to correctly apply the classes manually (and remove them), on actions such as hover, type, etc.
Suggested solution
A configuration option (generally to be used with userEvent.setup()) names pseudoStates with the following form:
typePseudoStates=Record<"hover"|"focus"| ... ,{// Class to be applied to element when it should be in the pseudo-stateclass?: string// Other options, such as for setting a "data-*" attribute instead}>
Additional context
If you think this is a good idea which fits with testing library, I would be willing to make a PR for this.
The text was updated successfully, but these errors were encountered:
Problem description
Currently, it is impossible to test hover states with JavaScript. One common solution for this is to use a special class for hovered elements instead of the pseudo-class
:hover
.In storybook, there is an addon for this. There's also one (which I use) for postcss, which is great: replaces
:hover
in CSS with.\:hover
, so the hover states is activated withclass=":hover"
instead of a real hover.Note that this works with all pseudo-states, not just hover. The issue is that it is difficult to correctly apply the classes manually (and remove them), on actions such as hover, type, etc.
Suggested solution
A configuration option (generally to be used with
userEvent.setup()
) namespseudoStates
with the following form:Additional context
If you think this is a good idea which fits with testing library, I would be willing to make a PR for this.
The text was updated successfully, but these errors were encountered: