[Switch] inputProps can take additional props

[Natalia504]

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

This change allows for additional attributes to be forwarded to the input element via inputProps.
This currently exists in InputBaseComponentProps here: https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/InputBase/InputBase.d.ts#L54-L58

[mui-pr-bot]

No bundle size changes comparing 192b426...b725602

Generated by 🚫 dangerJS against b725602

[Natalia504]

@oliviertassinari , here's sandbox for the issue that this PR is resolving:
https://codesandbox.io/s/material-demo-f6m52?fontsize=14&hidenavigation=1&module=%2Fdemo.tsx&theme=dark
Would this suffice?

[oliviertassinari]

Is this related to #18874? It sounds like something we should have a systematic solution for, not a one case exception.

[eps1lon]

Thanks for working on this.

Could you add a test to showcase what this fixes? It's not obvious to me why we need this change.

[eps1lon]

The problem is that this will not catch excess props that are actually wrong (such as those from typos or accidental wrong names.

[oliviertassinari]

The codesandbox shows the following pattern:

<Switch
  checked={checked}
  onChange={toggleChecked}
  inputProps={{ "data-testid": "test" }}
/>

The pull request seems to apply the same solution to the SwitchBase as we use with the InputBase:
https://github.com/mui-org/material-ui/blob/e59dbe3b0da43414dc64a660015f49b21c391c06/packages/material-ui/src/InputBase/InputBase.d.ts#L55-L58

---

@eps1lon On one hand, it would be more consistent, but on the other hand, we have microsoft/TypeScript#28960 and the fact that we encourage custom input component implementation that we don't with the switch, radio, and checkbox.

What would be best?

[eps1lon]

I need to think about this more. I think I'd rather encourage explicit any casting (not adding [arbitrary: string]: any;) so that you're responsible about usage rather than doing it all the time with some false passes.

[afholderman]

@eps1lon @oliviertassinari @Natalia504

What do you think of adding something like this to the index.d.ts:

export type StandardInputProps<E = React.InputHTMLAttributes<HTMLInputElement>> = E | {
  [arbitrary: key]: any;
}

Then for instance inputProps could be changed to StandardInputProps here and StandardInputProps<React.InputHTMLAttributes<HTMLInputElement | HTMLTextAreaElement>> here.

[oliviertassinari]

@afholderman I believe the InputBase case is a bit different to the SwitchBase, it's not uncommon to use a different implementation of the <input> element.

[oliviertassinari]

Maybe we should give up on the changes, and ask developers to manually cast?

[afholderman]

@oliviertassinari passing data attributes down is a supported use case by React so we should try to find a solution for this issue. Especially with growing adoption of testing-library as a hooks compatible replacement for enzyme which supports the use of data-testid to query the DOM.

[oliviertassinari]

@afholderman Why using a test-id over the accessible feature of the element (name, label, etc)?

[oliviertassinari]

It has been a month. I believe we can close the pull request with #18902 (comment) as a recommended approach :).

[t0wer001]

Just ran into this issue. And even from the suggestions here I am not exactly sure how to get around it.

Do you have an example with the casting explicit any as mentioned in #18902 (comment)

My current work around by applying the data-testid directly on the component and then acces the child nodes until I reach the input:

component:

<Switch
  data-testid="my-test-id"
/>

test:

clickSwitch: () => {
  const wrapperNode = getByTestId('my-test-id')
  const switchNode = wrapperNode.childNodes[0].childNodes[0]

  fireEvent.click(switchNode as HTMLElement)
},