JSX prop with dash is not type checked

[agentcooper]

TypeScript Version: 3.5.1

Search Terms: jsx, dash, props

Code

declare namespace JSX {
  interface ElementAttributesProperty {
    props: any;
  }
}

class MyComponent {
  props: {
    foo?: string;
  }
}

// OK
const el1 = <MyComponent foo="bar" />;

// OK, fooBar is incorrect prop
const el2 = <MyComponent fooBar="bar" />;

// Not OK, foo-bar is incorrect prop, but not reported
const el3 = <MyComponent foo-bar="bar" />;

Expected behavior:

Expected error on el3.

Actual behavior:

No error on el3.

Playground Link

[RyanCavanaugh]

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

[agentcooper]

@RyanCavanaugh Got it. Does it make sense to have an option to turn off this special case for data- and aria- properties? This is unexpected behavior in non-DOM environments.

[RyanCavanaugh]

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

[typescript-bot]

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

[Pomar81]

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

[layershifter]

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

[RyanCavanaugh]

I see at least three possible interpretations here and I'm not sure which people are going for:

• Have another option that controls whether dash-named properties get special treatment
• Hardcode data- and aria- to be the only allowed special names
• Only allow dash-named properties for intrinsic elements

Is this actually coming up as a problem? Standard props are never named with dashes so it seems like a very difficult mistake to make.

[Pomar81]

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

[bradleyayers]

This came up as a problem for me, when converting HTML to JSX (specifically MJML to mjml-react), and forgetting to convert some of the dashed prop names to camel case. There were no type errors, and essentially no validation on the props that were copied across. I was open to solving this with an ESLint rule, but there appears to be no ESLint rule either.

[Peeja]

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.

[canonic-epicure]

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>