Open bradzacher opened 1 year ago
Technically it's a feature request, not a bug report, because the current behaviour is working as intended
@RyanCavanaugh what additional feedback would you like for this?
We've found at scale it's a problematic hole in types.
It's very easy to think you're doing the right thing (eg passing aria-label="foo"
to a component) without realising that the target doesn't actually forward that property on to the host components.
It creates a11y holes in codebases :(
At canva we've added a lint rule to completely ban passing all kebab-cased attributes on non-host components and instead defined our own types using camelCase (eg ariaLabel
) so that we can close the holes.
It's not perfect - it's a bit clunky because we need to case-by-case use a disable comment on components which pass-through props to the host component.
Having full support would go a long way to improve a11y within JSX.
Totally agree, this would be nice to have. Any ways to get this fixed somehow in the future? :)
Another thing to note here is Web Components. There is no rule or best practice that says you should not create Web Components with attributes that have no dashes, and in fact there is some push to require Web Components to have dashes in their attributes (if I'm understanding the original proposal correctly). As mentioned in this comment, declarative frontend libraries like htmx make heavy use of dashed attributes.
Also, because HTML elements are case-insensitive, it is unwise to use camel-cased attributes for Web Components, as it could produce inconsistent or unexpected behavior at runtime. So the only option for Web Components in JSX to have type-safe attributes is for them to be lowercase and all-one-word, which seems like a bothersome restriction that TypeScript should impose when the DOM itself does not impose it. Even then, if someone does use a Web Component JSX element with an extra attribute and mistakenly includes a dash, that extra attribute will look like it is valid, even though it is not.
Given all this, I think it is reasonable for a developer to expect that TypeScript would be able to validate custom JSX attributes, and it's a shock to find that these attributes become type-unsafe as soon as you include a dash in their name.
Bug Report
Reference: https://github.com/microsoft/TypeScript/issues/32447
I thought it was a good idea to reopen this given it's been 4 years and TS's features have advanced substantially since that last issue was filed and closed.
Quoting @RyanCavanaugh
Given we now have template literal types - this is probably ripe for revisiting!
🔎 Search Terms
jsx dash property missing error kebab case
🕗 Version & Regression Information
⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
This errors on the component, not the property
These do not error at all
🙂 Expected behavior
This should error on the property - but it errors on the component instead
Should error because it doesn't match the defined template literal mapped type
Should error because the property doesn't exist