[Slider] Improve TS definition of unstyled

[mnajdova]

After doing some stress test for creating styled slider with TS I faced some issues that are fixes in this PR:

• add overrides point for the styleProps
• made as prop option on the componentsProps.root

[mnajdova]

@eps1lon should we add separate testModuleAugmentation for the @material-ui/unstyled package?

[mui-pr-bot]

No bundle size changes (experimental)

Generated by 🚫 dangerJS against 4a78630

[eps1lon]

@eps1lon should we add separate testModuleAugmentation for the @material-ui/unstyled package?

Sounds good!

[mnajdova]

@eps1lon should we add separate testModuleAugmentation for the @material-ui/unstyled package?

Sounds good!

@eps1lon added, I just copied the script. Maybe I should have added the test inside the @material-ui/core too, but I think it's better to isolate them by package. Anyway let me know what you think.

[oliviertassinari]

@mnajdova Are we sure about these types? I'm lost when I look at them. In MUI-X @dtassone has used any

Suggested change

	root?: {
	as: React.ElementType;
	styleProps?: Omit<SliderUnstyledTypeMap<P, D>['props'], 'components' | 'componentsProps'>;
	as?: React.ElementType;
	styleProps?: Omit<SliderUnstyledTypeMap<P, D>['props'], 'components' | 'componentsProps'> &
	SliderStylePropsOverrides;
	};
	root?: any;

which might be too loose, but seems still better.

I mean, for instance, if I want to add an extra data- attribute it fails:

import * as React from 'react';
import SliderUnstyled from '@material-ui/unstyled/SliderUnstyled';

export default function UnstyledSlider() {
  return (
    <SliderUnstyled componentsProps={{ root: { 'data-foo': 'bar' } }} defaultValue={10} />
  );
}

---

On styleProps specifically, I also don't see why we use SliderUnstyledTypeMap. As far as I know, the correlation between the props and what's available in this prop is "light". For instance, in the slider, we have an extra marked property:

https://github.com/mui-org/material-ui/blob/d36858d36741bb57facb7f1e91d0d2d4d760b4bb/packages/material-ui-unstyled/src/SliderUnstyled/SliderUnstyled.js#L624

[michaldudak]

I'm in favor of using specific types instead of any whenever possible. This way developers get prop validation for free from Typescript (this can be especially important if a component with mandatory props is used in a slot).
The data-foo you mentioned is a bit of an edge case as data attributes are not specified in any HTMLAttributes. To use them in a type-safe way, module augmentation should be used. However, IMO this should be the only case where developers should resort to module augmentation when providing componentsProps.

[oliviertassinari]

@michaldudak data-*, tabindex, aria-*, they all fail. We don't accept any other props than as and styleProps. The issue for me is that we don't have any easy way to know what are types accepted. A developer could use components to render something completely different.

[michaldudak]

In this case yes, they'll fail without module augmentation. But we could use what I made in https://github.com/mui-org/material-ui/blob/d587b1eab467739a2a143f0cd49bfc10cc35ba74/packages/material-ui-unstyled/src/SwitchUnstyled/SwitchUnstyled.tsx - when you pass in a component/intrinsic element in components prop, the corresponding componentsProps expects props for this exact component/element. data-* attributes obviously aren't supported this way, but all the others are (including aria-*)

[oliviertassinari]

when you pass in a component/intrinsic element in components prop, the corresponding componentsProps

@michaldudak This approach seems to have potential 👍 .

Should we open a new issue to keep track of this problem?

[michaldudak]

Sure thing: #26810