[core] Allow data-* attributes on all *props

[MarksCode]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

As seen here: https://codesandbox.io/s/checkboxes-demo-material-ui-forked-61wy40, adding a data-* prop throws an error:

Type '{ "data-cy": string; }' is not assignable to type 'InputHTMLAttributes'.

Expected behavior 🤔

data-* props should be allowed, like in the TextField component.

Steps to reproduce 🕹

https://codesandbox.io/s/checkboxes-demo-material-ui-forked-61wy40

Context 🔦

I want to add a data-* prop for testing.

Your environment 🌎

Latest TS, latest MUI

[alannungaray]

A long time ago I had the same issue and a good person on internet answer this:

A way to add custom properties to our project is defining it on our modules.

Example:

import * as React from 'react';
import ReactDOM from 'react-dom/client';
import { StyledEngineProvider } from '@mui/material/styles';
import Demo from './demo';

//Extend attributes of attributes
//Definition start
type DataAttributeKey = `data-${string}`;
declare module 'react' {
  interface HTMLAttributes<T> extends AriaAttributes, DOMAttributes<T> {
    [dataAttribute: DataAttributeKey]: unknown;
  }
}
//Definition end


ReactDOM.createRoot(document.querySelector("#root")).render(
  <React.StrictMode>
    <StyledEngineProvider injectFirst>
      <Demo />
    </StyledEngineProvider>
  </React.StrictMode>
);

I hope that can help you as a work around.

[mnajdova]

Interesting, we are likely going to have this problems with @mui/base's componentsProps. I assumed using HTMLAttributes would be sufficient. cc @michaldudak

[michaldudak]

That's what we have *ComponentsPropsOverrides interfaces for. You can augment the module that hosts them and create your own definition with the custom attributes.

[mnajdova]

That's what we have *ComponentsPropsOverrides interfaces for. You can augment the module that hosts them and create your own definition with the custom attributes.

I understand, but should we maybe be less strict and allow data-* attributes?

[michaldudak]

This would basically mean accepting Record<string, string> in addition to what's already accepted (unless we go really fancy with something along Key extends `data-${infer AttributeName}` but I don't think this would fly with TS 3.5).

I remember we discussed a similar problem in the past. One issue with this approach is that it's very permissive (and it's not possible to make it stricter), whereas if we make it strict by default, developers can loosen the restrictions by module augmentation. I'm not saying we shouldn't do it, but we have to be aware of this.

[mnajdova]

Alright, let's keep the issue open and see if it will get more traction.

[clementlize]

Hi there, I recently faced the exact same problem, while trying to add a "data-test" property to a checkbox using inputProps.

I was really surprised at first because it is something you can do on textFields. I then went to the code and found out that there is a difference between the 2 types files about the inputProps. The inputBase one allows us to add as many arbitrary properties as needed.

The question is then: why is there a difference between the 2 implementations? Is one of the 2 a bug, or a legacy?

[MonstraG]

Trying to write a test for <Badge/>'s dot to be shown:

		<Badge
			invisible={invisible}
			anchorOrigin={{
				vertical: "bottom",
				horizontal: "right"
			}}
			overlap="rectangular"
			color="primary"
			variant="dot"
			slotProps={{ badge: { "data-testid": "my-cool-dot-id" } }}
		>
			<SearchIcon />
		</Badge>

And that, of course, fails without the typescript module thing workaround.

... Key extends `data-${infer AttributeName}` but I don't think this would fly with TS 3.5).

In project's readme it is stated that TS min version follows Definitely Typed, which does TS from 2 years ago. TS 4.0 released almost 3 years ago, so if that is the only hold up, we can maybe raise min TS version? This would be convenient to do now, with mui v6 on the horizon.