Typescript: JSX prop with dash is not type checked

Created on 17 Jul 2019  ·  10Comments  ·  Source: microsoft/TypeScript

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

Add a Flag Working as Intended

Most helpful comment

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

All 10 comments

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

@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.

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

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

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

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

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.

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

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.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

blendsdk picture blendsdk  ·  3Comments

seanzer picture seanzer  ·  3Comments

fwanicka picture fwanicka  ·  3Comments

jbondc picture jbondc  ·  3Comments

wmaurer picture wmaurer  ·  3Comments