AR-748 Add Switch component

[justinanastos]

Please check the storybook deploy preview and visit Switch's docs tab for usage examples!

This is intended to provide a minimum viable abstraction for a Switch component. All use cases are documented (hopefully) in the storybook docs. The props are taken directly from react-spectrum, which feels fine to me. We also make available Toggle.Label if you want to use the label separately just for rendering something that looks like a toggle label. When using this, you should wire up aria-labeledby on your own.

This was originally titled Toggle, but the underlying <input> 's role should be role="switch", so I decided to name this Switch instead. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Switch_role

Contributes to AR-748

Depended on by mdg-private/studio-ui#2953

[cheapsteak]

Desculpe; was focusing on addressing issues with schema page before we ship

Looking forward to having indeterminate checkboxes!

One feature that this PR doesn't have yet (that doesn't necessarily need to block), is the ability to not use the label that come bundled with these components and only use e.g. Checkbox as the replacement for <input type="checkbox"/>

For Checkbox and Toggle, the labeling text is placed to the right of the control
In one of the places where we use this, the actual "label" is to the far left, and there's another indicator to the immediate left

I hope that the solution to that would not be to add a boolean flag to flip the direction.

One way to go could be to not render the <label/> if no children are passed
Needing to pass ids (the route for + aria-labelled-by leads) is tedious (have to guarantee unique ids and match them)
Nesting is the most convenient DX for labeling inputs, but the label element must not contain any nested label elements

Another could be to not bundle <label/> until we find cause to (perhaps when our UI needs to support RTL languages and we need to handle auto-direction-flipping);
imo bundling <label/> into these components doesn't save that much time, but does add quite a bit of rigidity.

---

Mostly unrelated to the above - I'm curious if we intend to use the Checkbox component for Explorer's query builder?

Having query builder's checkboxes be able to represent indeterminate state would be fantastic, and I assumed this was what motivated us to work on a checkbox for spacekit; but the stylings don't match; would it make more sense for that component to directly use @react-aria's useCheckbox instead then?

[justinanastos]

@cheapsteak I'm terrible at framer motion. I couldn't get the animation to look smooth with a spring; I really miss react-spring's presets that let me just choose "stiff" instead of "bouncy". Any tips there would be appreciated.

[cheapsteak]

I truly appreciate you going to the effort of splitting out label into a separate thing 🙏

There are some amazing things being done in Space Kit in terms of CI, automation, documentation

I must however once again confess that the approach that has been decided on for this repo in terms of API design, especially with regards to whether its primary purpose should be to "restrict" vs to "empower" (and how important it is to protect consumers from themselves) is one that continues to be incompatible with my personal beliefs. And that's fine.

We may perhaps be spending an unnecessary amount of energy trying to find agreement on things that perhaps only you and I care about, and matter little in the scheme of our org's and our team's objectives. At the end of the day, since other consumers of Space Kit need to use "Toggle" outside of studio-ui, it's more important for it to be available so that we're not blocking those teams, than it is for it to be available in a form that I approve of

There are five other contributors to studio-ui (not including the two of us or Danielle), not to mention Jay and Trevor who also consume and can contribute to this repo. Rather than let disagreement syphon any more of our energy, I think it may be better for all our sakes that I take an approach of "disagree, and get out of the way"

[Jephuff]

Can we use dark instead of midnight to keep it consistent with our theme names everywhere else?

[justinanastos]

Thanks for starting this conversation @Jephuff ! After talking with @jglovier we should rename this to dark because using midnight is an implementation detail 👍

[justinanastos]

Done.

[jglovier]

Can we speed this up a little, say 150ms?

Suggested change

	transition={{ duration: 0.5, type: "tween", ease: "easeOut" }}
	transition={{ duration: 0.15, type: "tween", ease: "easeOut" }}

[jglovier]

Looking great!! ⚡ ⚡ ⚡

I noticed that there is a disabled state in the Story docs, but it's a little different than I'd expect the disabled state to look. I would assume that disabled would mean the setting is off and cannot be turned on. Also, the disabled state could use a lighter opacity on the labels as well, so it's clear that the setting is disabled and not just the toggle switch.

[justinanastos]

Hey @jglovier !

Looking great!! ⚡ ⚡ ⚡

I noticed that there is a disabled state in the Story docs, but it's a little different than I'd expect the disabled state to look. I would assume that disabled would mean the setting is off and cannot be turned on. Also, the disabled state could use a lighter opacity on the labels as well, so it's clear that the setting is disabled and not just the toggle switch.

The dark-mode disabled state is definitely not what it should be because I don't have any examples of what exactly it should be 😃 I imagined the disabled state to just mean you can't change it, not that it was selected or unselected. I can mess with the opacity and we can come back to it if it lands like this 😃

[justinanastos]

@jglovier I'm going to change the animation to copy the animation in Modal because that seems to be configured to be pretty slick. It feels better and is much faster now.

Regarding the disabled color, I def need some feedback on it; namely what should it look like in dark mode. Just changing the opacity looks wrong because then it's blending with the dark background color. Right now the color of the selected state gets lighter when it should get darker; but I don't think this is a blocker for merging and releasing since we're not using it yet and I'm anxious :-D If it's something that we can put together quickly then I'm happy to do it now!

[jglovier]

I imagined the disabled state to just mean you can't change it, not that it was selected or unselected.

Ohhh, I guess I misunderstood the intent. What would be an example of where the toggle would appear, but the user would not be able to change it?

[justinanastos]

I imagined the disabled state to just mean you can't change it, not that it was selected or unselected.

Ohhh, I guess I misunderstood the intent. What would be an example of where the toggle would appear, but the user would not be able to change it?

@jglovier I can't think of any!

[justinanastos]

I imagined the disabled state to just mean you can't change it, not that it was selected or unselected.

Ohhh, I guess I misunderstood the intent. What would be an example of where the toggle would appear, but the user would not be able to change it?

@jglovier I thought of one. A form that has several switches and you want to disable them all while a mutation is in-flight.

[jglovier]

I imagined the disabled state to just mean you can't change it, not that it was selected or unselected.

Ohhh, I guess I misunderstood the intent. What would be an example of where the toggle would appear, but the user would not be able to change it?

@jglovier I can't think of any!

Maybe we don't need a disabled state? If the user cannot change it, I would suggest we always simply don't show it if the user doesn't have access to modify.

If that is not preferable, however, here is my suggestion for tweaking...

Regarding the disabled color, I def need some feedback on it; namely what should it look like in dark mode. Just changing the opacity looks wrong because then it's blending with the dark background color.

Changing opacity to something like 50% for the entire element (i.e. setting name, state label, and toggle switch) is preferable. It's a relatively common pattern to use when something is disabled, and it's what we're kind of trying to simulate by changing colors but instead of simulating we're actually doing it! 😄 I would just also add a tooltip to say "You cannot change this setting."

Tailwinds appears to support opacity-50, although apparently we don't have it in our Tailwinds.

[justinanastos]

🚀 PR was released in v7.8.0 🚀