Enforce property rules on kebab-cased JSX attributes

[bradzacher]

Bug Report

Reference: #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

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

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

• This is the behavior in every version I tried

⏯ Playground Link

Playground link with relevant code

💻 Code

type Props = {
  a?: string,
  'some-kebab-property'?: boolean;
} & {
  [k in `data-${string}` | `aria-${string}` | `hello${string}`]?: string
} & {
  [k in 'kebab-case1' | 'kebab-case2']?: string
};
function Component(props: Props) { return null }

function Other() {
  <Component
    a={1} // ✅ expected error
  
    b={1} // ✅ expected error
    
    hello={1} // ✅ expected
    helloThere={1} // ✅ expected
    
    aria-label="" // ✅ valid
    data-foo="" // ✅ valid
  />;

  // ❓ errors on the component, rather than the property
  <Component
    kebab-case1={1}
    kebab-case2={1}
  />;

  // ❓ errors on the component, rather than the property
  <Component
    some-kebab-property={1}
  />;

  <Component
    data-bar={1} // ❌ should error but doesn't
  />;

  <Component
    property-that-definitely-doesnt-exist-yet-ts-does-not-error-on-it={false} // ❌ should error but doesn't
  />;
}

🙁 Actual behavior

This errors on the component, not the property

  <Component
    kebab-case1={1}
    kebab-case2={1}
  />;

  <Component
    some-kebab-property={1}
  />;

These do not error at all

  <Component
    data-bar={1}
  />;

  <Component
    property-that-definitely-doesnt-exist-yet-ts-does-not-error-on-it={false}
  />;

🙂 Expected behavior

This should error on the property - but it errors on the component instead

  <Component
    kebab-case1={1}
    kebab-case2={1}
  />;

  <Component
    some-kebab-property={1}
  />;

Should error because it doesn't match the defined template literal mapped type

  <Component
    data-bar={1}
  />;

Should error because the property doesn't exist

  <Component
    property-that-definitely-doesnt-exist-yet-ts-does-not-error-on-it={false}
  />;

[MartinJohns]

Technically it's a feature request, not a bug report, because the current behaviour is working as intended

[bradzacher]

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

[nstrelow]

Totally agree, this would be nice to have. Any ways to get this fixed somehow in the future? :)

[stevematney]

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.

[trusktr]

It'll be so nice when this is fixed.

I really want to avoid allowing people to

return <some-element with-any-prop-that-does-not-exist />

This current behavior is problematic because it means typos silently fail. If the following is valid for the element:

return <some-element some-prop={123} />

then this one with a typo silently fails (undesirable):

return <some-element some-rop={123} />

Maybe it should be a new option to enable the feature, for backwards compatibility, such as

{
  "compilerOptions": {
    "strictJsxProps": true
  }
}

The reason for backwards compatibility is because some people might be relying on arbitrary "attributes" for styling:

return <>
  <any-el some-arbitrary-attribute></any-el>
  <style>
    [some-arbitrary-attribute] { color: rebeccapurple }
  </style>
</>

When they enable the new option, they will need to expand JSX.IntrinsicAttributes to make their custom attributes check out.