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.
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:
data- and aria- to be the only allowed special namesIs 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.
Most helpful comment
It would be great if we could allow only
data-andaria-properties for JSX IntrinsicElements but throw an error in the other cases.