feat(theme): add/update form component themes

[TylerAPfledderer]

Description

This is part of the Implementation of the DS v1

Add or updates theming configs for form components to adhere to the new design system.

• Adds/updates theming for Radio, Switch, Checkbox, Select (Dropdown), and Input
• Creates custom component for Input
• Adds Storybook stories for each component
• Update other components or pages where necessary for immediate inclusion
  • This is includes adding Select implementation as a replacement for the react-select lib.

Related Issue

Closes #8630

[gatsby-cloud]

✅ ethereum-org-website-dev deploy preview ready

• Deploy preview
• Build logs · 42m build time

[pettinarip]

We now use this search "button", and on this PR we have the old one. maybe we should update it if possible

I'll update the branch now but I see the same search button here and in prod 🤔 I'm a bit confused on what you see as the difference.

[pettinarip]

The read-only should not have hover behavior because it's read-only.

@TylerAPfledderer is that something you know how to add?

[TylerAPfledderer]

The read-only should not have hover behavior because it's read-only.

@TylerAPfledderer is that something you know how to add?

@pettinarip The CSS selector variable _notDisabled in the component.utils file can be extended to &:not([data-disabled], [disabled], [data-readonly]) for the control element.

Updates to:

[_notDisabledReadOnly]: {
  "*:hover > &": {
    bg: "primaryHover",
    borderColor: "primaryHighContrast",
  },
},

Are you looking for the cursor to change as well, similar to the disabled radio?

[pettinarip]

Are you looking for the cursor to change as well, similar to the disabled radio?

I don't think that is necessary for this case. What do you think @nloureiro ?

[nloureiro]

The cursor should not indicate the is an action there.

In the case of the disabled should have the not-allowed

 .not-allowed {
  cursor: not-allowed;
}

[nloureiro]

After a second review, I want to request a small change on the hover color for the checkbox and radio, the blue was too intense.
changed to body medium

[nloureiro]

On the switch, are we using the strong grey as a default?
Maybe that's me but I could not be sure on chromatic preview

[TylerAPfledderer]

@pettinarip @nloureiro should be good now for another review.

[TylerAPfledderer]

For whatever reason, using border and borderColor here works fine for Checkbox, but rendered in reverse order for Radio, cause the borderColor styling to be overriden in the CSS by the border.

Now this is probably due to using the default theming which includes an invalid styling (which would be odd for the inconsistency), but I think a refactor in how I am applying these common props might fix it (send these props to the checkbox and then import the checkbox styles to the radio and switch). Otherwise, this might be a compiling bug.

Either way, I think the reorganizing and addressing the prop issue should be saved for a separate PR to get this PR over the finish line... unless you would like for it to be resolved here.

[pettinarip]

Ok, thanks @TylerAPfledderer.

[pettinarip]

@TylerAPfledderer I've updated the hover colors to match the DS. Not sure if there is a more concise way for these selectors but it works as expected.

We want to display primary.hover on checked and body.light on unchecked ones.

[pettinarip]

@TylerAPfledderer I had to do this to catch the two possible states and override the common styles. The switch is slightly different in terms of hover styles than the radio and checkbox (check DS).

[pettinarip]

Looks good. Lots of good stuff here, thanks @TylerAPfledderer

[nloureiro]

Looks good!!!