[material-next][Switch] Add `Switch` component

[lhilgert9]

This issue is to track the work for adding the Switch component to @mui/material-next, moving forward the Material You effort (https://github.com/mui/material-ui/issues/29345)

Material You Swicth specification: https://m3.material.io/components/switch/overview

Migration Guide steps

• [x] Copy component files from material (v5) to material-next: https://github.com/mui/material-ui/pull/39887
• [x] ~Remove deprecated components and componentsProps props:~ Skipped, no props to remove
• [ ] Drop support for ThemeProvider in favor of CssVarsProvider: https://github.com/mui/material-ui/pull/40442
• [x] Migrate component to Typescript: https://github.com/mui/material-ui/pull/39894
• [ ] Refactor component to use Base UI hooks: useSwitch & useSlotProps: https://github.com/mui/material-ui/pull/40442
• [ ] Implement Material You design specs: https://github.com/mui/material-ui/pull/40442
• [ ] Add component playground to v5 docs: https://github.com/mui/material-ui/pull/40442

Note: This comment will be updated to show the progress and list possible issues.

@DiegoAndai

[lhilgert9]

@DiegoAndai I worked on the next steps and came to the point where I asked myself whether we wanted to keep the current structure of the switch component or align it with the structure of @mui/base. So there are two options:

1. @mui/material:

   <Root>
   <SwitchBase/> //has to be copied in @mui/mui-material-next
   <Track/>
   </Root>

2. @mui/base:

   <Root>
   <Track/>
   <Thumb/>
   <Input/>
   </Root>

   I would prefer the second option, as it is easier to implement the useSwitch hook, but there would be a lot of breaking changes. However, I find this justifiable, as the structure of the components in mui is finally the same and developers do not have to differentiate.

[DiegoAndai]

it is easier to implement the useSwitch hook, but there would be a lot of breaking changes

I would also prefer option 2. What are the breaking changes that would be required?

[lhilgert9]

What are the breaking changes that would be required?

• The SwitchBase-component will be removed
• The switchBase-class will be removed
• The SwitchBaseProps will be replaced with the UseSwitchParameters in the SwitchProps
• The value-prop can be removed
• icon and checkedIcon could be implemented as slot components, so we can use a hook as default checkedIcon like in the MD3 docs

I think that must have been all of them. If nothing speaks against it, I would try to implement the whole thing and we can then make further adjustments in the PR.

[DiegoAndai]

• The SwitchBase-component will be removed
• The switchBase-class will be removed
• The SwitchBaseProps will be replaced with the UseSwitchParameters in the SwitchProps

I'm not so worried about these ones, the whole idea of the Base UI refactor is to remove code duplication, so removing SwitchBase makes sense.

• icon and checkedIcon could be implemented as slot components, so we can use a hook as default checkedIcon like in the MD3 docs

This one makes sense as well, we'll soon deprecate these in favor of the slots pattern

• The value-prop can be removed

Is there a use for this prop? I wouldn't remove it unless there's an advantage of doing so or if it's difficult to keep for some reason.

I would try to implement the whole thing and we can then make further adjustments in the PR.

Let's do that 🚀 let me know if there's anything I can help you with. Let's try to keep breaking changes to a minimum besides the ones listed above. If you find any improvements/fixes on the Base UI side, let us know so we can discuss 🙌🏼.

[lhilgert9]

@DiegoAndai I didn't quite understand myself what the value-prop was for, but it was only passed on to the SwitchBase and as this is no longer the case, I would have seen no reason to keep it. Unless we can somehow incorporate it into the useSwitch-hook, in case it does have a function.

[DiegoAndai]

@lhilgert9, the SwitchBase component forwards the value prop to the input element; let's keep that for now.

[oliviertassinari]

Should we add the "on hold" label to all the MD3 issues?

I can't think of a supporting reason to work on those until the MUI System and Base UI are finalized. What I see is that it would slow us to get Material UI v6 out of the door, while also taking a significant risk for needed to redo the effort, there is a good chunk of uncertainties:

• MUI System might require us to rewrite @mui/material-next
• The merge with Joy UI might require to rethink of the whole implementation of Material UI v7.
• Base UI API might improve, to a state where we don't need to rely on the hook API, and instead where we can use the component API that is recommended in our docs.
• I don't think we can release a major style change without having all the components with an unstyled counterpart that developers can migrate to, so it seems to me that Base UI completeness and great DX should come first.

[DiegoAndai]

Should we add the "on hold" label to all the MD3 issues?

It's "on hold" regarding the Core team. Do you think we should also hold on community contributors for it?

I see benefits in having the community continue the effort:

• It gives early access to people who need it
• It gives us a blueprint for v7: The style changes, composed classes, and Base UI refactors should be the same, or at least very similar, so we can effectively use it as a guide. This is useful so we know what things to deprecate earlier.

What do you think?

cc @mnajdova to get your opinion on it as well

[mnajdova]

I agree internally, that we should not work on the migration for now. For external contributions, I would leave that up to @DiegoAndai. My feeling is that we should not receive contributions. Few reasons why:

• it could be distracting working on one thing and reviewing something else (or not, depending on you Diego :))
• we could have a "wrong starting point" for v7, considering we would be iterating on this code - not on the original one
• there would likely be a lot of lost effort, depending on the decisions we would make for how to build the components

[DiegoAndai]

@mnajdova, fair points. I'm marking the MD3 issues as "on hold" for now.

@lhilgert9 I hope this doesn't discourage you from contributing to other Material UI issues. You've been making significant contributions. We will need help with v6 soon, and in the second half of the year, we will resume the MD3 work 😊.

[lhilgert9]

@DiegoAndai Sounds understandable to me. I'll see if I can contribute to V6. I will do my best. I'm looking forward to learning and developing new things ☺️🚀. Do we also put the ButtonGroup on hold or do we want to finish it since it is as good as finished? On the other hand, there is still a lot to do on the normal button component, so on hold probably makes more sense.

[DiegoAndai]

Do we also put the ButtonGroup on hold

I replied on the ButtonGroup PR 🙌🏼