TypeScript: JSX prop with dash is not type checked

It would be great if we could allow only data- and aria- properties for JSX IntrinsicElements but throw an error in the other cases.

If people start running into a lot, we could think about it, but it hasn’t seemed to have been an issue so far

@RyanCavanaugh I support @agentcooper and @Pomar81 there, it looks like unexpected behavior 💭

I believe we just hit this on MDN too: a user reported no aria-label on one of our buttons which had been set on our component, but on the aria-label prop, whereas this component required an ariaLabel prop.

Due to this behaviour in TypeScript, we got absolutely no indication of the prop naming mismatch, which is surely the point of typing our component props. Could this bug be reopened?

This is the intended behavior because of data- and aria- properties. If we ever get regex-based property names, we’ll revisit.

@RyanCavanaugh Time to revisit this issue, since template string types appeared?

My use case is that I want to translate all properties like style:${ name } to their corresponding reactive applicators. And now such properties are not typechecked even if props is defined as:

props : { [ key in 'class' | 'style' | `style:${ string }` ]? : string }

So the following declaration is accepted fine (note the typo):

<ProjectPlan styZle:min-width="300px" style="color: red" projectData={ this.launcher.projectData }></ProjectPlan>

from my side, it would be great if TS Team could apply last option

This also seems to accept propName- as a valid case. We had a typo propName-={} and because of this it didn’t catch it. I think it should consider nothing after - as an invalid case. I guess that check shouldn’t break any aria related regex

Hi, are we have news about it? This is creating some problems for me.

This issue has been marked ‘Working as Intended’ and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Another reason: Let’s say you are spreading { ...rest } to a component, but overriding a prop, i.e.

<div
   {...rest}
   aria-label="label"

You’d want to have the component’s props be something like Omit<HtmlProps<HtmlDivElement>, 'aria-label'> , to disallow aria-label from being passed, since it is overwritten. However, this currently does not work, as aria-label is always allowed to be passed.

I’d say it could be useful to type restrict or control which hyphen-cased props are allowed, because sometimes in the component’s internal logic, we are not forwarding { ...rest } to the DOM element, and only forward a subset of props, which gives an incorrect notion that a certain prop is supported (or passed down to the dom element) which is not necessarily the use-case.

I think this is the biggest reason that this bug should be fixed. There is no guarantee that a component is spreading these props, so why always allow them? If a component did want to allow these props, they could always manually extend HtmlProps or AriaAttributes to their component’s props. But they should only be allowed if these are extended.

I’d say it could be useful to type restrict or control which hyphen-cased props are allowed, because sometimes in the component’s internal logic, we are not forwarding { ...rest } to the DOM element, and only forward a subset of props, which gives an incorrect notion that a certain prop is supported (or passed down to the dom element) which is not necessarily the use-case.

A similar scenario occurred in MUI DataGrid when we a user tried to pass data-* attributes which were actually not forwarded but the TS didn’t complain it.

A similar use-case is also mentioned by @Peeja above.

Note for other people searching for this:

Right now, it’s actually possible to create type-checked prefix:* attributes.

Definition:

interface Attributes {
    [key: `class:${string}`]: boolean;
}

Usage:

<div class:whatever={true}>
<div class:whatever={false}>
<div class:whatever> <!-- evaluates to true -->

Just hit this. We have a custom Button component. We forward a couple of data- attributes to the underlying button. We just tried to add another data- attribute to a Button, expecting it to pass through, but we didn’t realize we hadn’t forwarded that one yet. It type checked fine, because it was a data- attribute.

I would have expected it not to check the prop on the button, but to check it on the Button.

This is the intended behavior because of data- and aria- properties. If we ever get regex-based property names, we’ll revisit.