insin / babel-plugin-react-html-attrs

Babel plugin which transforms HTML and SVG attributes on JSX host elements into React-compatible attributes

Home Page:https://astexplorer.net/#/gist/0008d677e8156dab437be51d1fee1757/latest

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

How do you solve ESLint errors?

ericclemmons opened this issue · comments

Love this plugin. Use it everywhere.

Dunno what you do about ESLint errors:

Unknown property 'class' found, use 'className' instead react/no-unknown-property

Just turn it off?

I was planning to use the same list as https://github.com/yannickcr/eslint-plugin-react/blob/master/lib/rules/no-unknown-property.js so you can safely disable the rule, but am getting a bit hung up on how that rule allows you to pass regular attributes in certain cases, such as custom React components and custom HTML elements.

Custom React components I've used and created have followed the convention of using className, so transforming class to className works for them. Not so sure about other attributes, though.

Initial gut feeling was that we should do the full list of transformations for things which look like HTML tags, but only do classclassName for everything else. However, this breaks in cases where a component lets you customise what gets rendered by passing a tag name.

I'm also thinking the forhtmlFor transformation should be restricted to <label>, but I don't know if people out there are creating <Label> wrapper components which follow the htmlFor convention.

You also probably don't want to stop using this ESLint rule because it catches things like using incorrect casing for event handlers.

The solution is probably to create a PR to make the react/no-unknown-property rule customisable for the limited transforms this plugin currently performs.

I'm getting a better understanding of why this behaviour was removed from JSX!

I just noticed react/no-unknown-property supports the --fix option - does that make this plugin slightly redundant, given the potential it has to cause confusion?

I still prefer using this plugin because writing markup and using className has caused enough confusing for our front-end team using React/JSX.

Even for me, there's less cognitive switching when coding. Spending 2 decades writing HTML and all ;)

You can close this issue, if you'd like. I just disable the rule & deal with the minimal number of warnings that may crop up. I have tons more issues without this plugin, TBH.

  • Document recommended ignore config for react/no-unkown-property