Add interaction stories for buttons, number field, and anchor

[m-akinc]

Pull Request

🤨 Rationale

Part of #495

👩‍💻 Implementation

I had to make some changes in storybook-addon-pseudo-states to support our styling, but now we can pull in that fixed release and add some initial visual tests.

The way the addon typically works is that you set story parameters to select which component(s) should have the pseudo-state styling, e.g.

ButtonStory.parameters = {
  pseudo: {
    hover: ["#one", "#two", "#three"],
    focus: true, // means apply to all components
    active: ".some-class",
  },
}

However, this does work well with our matrix story approach. The effect of these parameters is just to set certain classes on the indicated elements. So, instead, we can bypass the story parameters and directly apply the classes to our elements. For example, any element with the class hover or pseudo-hover-all will be styled by the addon as if hovered.

NOTE: Because we have to put the classes directly on the elements in our Story html, we can't put them on any shadow DOM elements, e.g. the inc/dec buttons of the number field. However, puting pseudo-<state>-all on a host element will cause all elements in its shadow DOM to be styled as if they have that state. This can create some visuals that are practically impossible (e.g. a number field and both of its inc/dec buttons all having keyboard focus at the same time), but they are still useful from a visual testing standpoint.

The pseudo-states supported by the addon are:

• :hover
• :active
• :focus-visible
• :focus-within
• :focus
• :visited
• :link
• :target

It is only interesting to test states that we specifically style for, so generally, that is hover, active, and some form of focused. Because our components use both :focus-visible (focusVisible from FAST) and :focus-within, I'm not distinguishing the two, and I'm setting classes for both whenever we want to see "focused" styling. We could potentially test all combinations of these pseudo-states, but that seems unnecessary, especially considering that we want to test these states in conjunction with other appearance/config variations. So I'm limiting combination testing to just hovered+active, since that is a common use case for mouse-based interaction. To summarize, that means I'm proposing we test:

• hover (only)
• active (only)
• focused (only)
• hovered and active

Initially, I'm adding new test matrix stories for:

• anchor
• anchor-button
• button
• menu-button
• number-field
• toggle-button

These seemed to be some of the more interesting components in terms of having distinct keyboard-focused and/or active states, (in addition to hover, which applies to most/all? components).

Some combinations of interaction states with control attribute values aren't interesting, e.g. a disabled control with focus or active interaction state. In order to exclude certain combinations, we had to refactor the createMatrix utility function and introduce a new createMatrixInteractionsFromStates function.

🧪 Testing

Storybook visual tests

✅ Checklist

• I have updated the project documentation to reflect my changes or determined no changes are needed.

[m-akinc]

@mollykreis I would ask Malcolm, but he's out this week, so can you please buddy for me?