jsx-eslint
[New] Rule jsx-no-uppercase-data-aria-attributes
As per https://facebook.github.io/react/docs/dom-elements.html , data-* and aria-* attributes should be lowercase. This rule enforces that.
Justification to be added to recommended rules: Without this rule, data-myProp and aria-describedBy will both throw warnings. It's also pretty lightweight.
Small strange thing: no-typos.js tests were failing on master. I had to guess at the intention, but unsure how master was passing tests before.
There's a PR for the no-typos test, so you can actually ignore it. It happened due to a bump in ESLint that caused an unsupported case to be supported.
Hmm, just wondering, Is this still valid with React 16? https://facebook.github.io/react/blog/2017/09/08/dom-attributes-in-react-16.html
It seems the data attribute is no longer ignored, but it does get lowercased: https://codesandbox.io/s/6nx6p1r0rn
Otherwise looks good to me, ( but I'm not the one to decide if it should be included or not 😄 )
This is definitely still useful to avoid warnings, but not as critical as I thought previously (silently ignore the attribute).
The aria-* restriction could go in js-a11y, but the data-* rules would be irrelevant there. This is also clearly a react/jsx constraint and not an accessibility helper which is why it's documented in the 2nd paragraph of https://facebook.github.io/react/docs/dom-elements.html rather than just in https://facebook.github.io/react/docs/accessibility.html
Currently this rule does apply to custom AND host components. I could have restricted it to just host/HTML components, but the performance would suffer and complexity of the rule would increase with little reward: I find it very unlikely that custom components would have an attribute key named data-* or aria-* except as pass-throughs to HTML components.
Unlikely isn't impossible, however.
Using semantic HTML attributes is still part of a11y, including data- attributes.
