[Checkbox][Switch] Remove checked argument from onChange

[m4theushw]

Breaking change

function MyCheckbox() {
- const handleChange = (event: React.ChangeEvent<HTMLInputElement>, checked: boolean) => {
+ const handleChange = (event: React.ChangeEvent<HTMLInputElement>) => {
+   const checked = event.target.checked;
  };
  return <Checkbox onChange={handleChange} />;
}

function MySwitch() {
- const handleChange = (event: React.ChangeEvent<HTMLInputElement>, checked: boolean) => {
+ const handleChange = (event: React.ChangeEvent<HTMLInputElement>) => {
+   const checked = event.target.checked;
  };
  return <Switch onChange={handleChange} />;
}

---

• I have followed (at least) the PR section of the contributing guide.

Part of #20012.

This PR changes the signature of the onChange prop in SwitchBase to remove the second argument. Users can obtain the same outcome using event.target.checked.

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against 84fa324

[m4theushw]

We're relaying on a reference to the target now. If the checked prop is not updated, event.target.checked will be true again in next tick.

[eps1lon]

Good call pointing this out. The click() was missing an act() i.e. flushing of effects. The setProps was implicitly doing that.

The other problem is that the test was no longer testing the click() but rather setProps({ checked: false }). I changed the test so that we actually test `onChange={(event) => setChecked(event.target.checked)}: bacce0c

[oliviertassinari]

It also impacts the Checkbox. How about we update the migration guide as well?
Regarding introducing a deprecation in v4, I can't think of any obvious way to do such. Is it possible? Maybe not.

[m4theushw]

Regarding introducing a deprecation in v4, I can't think of any obvious way to do such. Is it possible? Maybe not.

I think that only with ESLint is possible to give such warning. However, the plugin we have is for internal use.

A bit hacky, but we could warn if event.target.checked was not used inside the onChange callback. The trade-offs are:

• Users that don't use it would still be impacted.
• We have to check if onChange returns a Promise.

[oliviertassinari]

@m4theushw Ok, I vote for not doing any deprecation, I think that it is only worth it if it's simple to put in place.