[dmitriid]

Exactly. It’s JS and not HTML.

Because in JS that attribute/property is `className`. Because `class` is a reserved name in JS.

Same goes for `htmlFor`, for example. So now you will have a situation where all props directly correspond to DOM APIs, and one prop that isn’t. A strange choice given how the stated goal is to be more consistent with DOM APIs.

[angersock]

And yet the entire reason for using JSX in the first place is that it looks like HTML. This is a reasonable change.

[danabramov]

So I wrote in detail why I think `class` is the right choice here. Hope it helps.

https://github.com/facebook/react/issues/13525#issuecomment-...

[dmitriid]

Leaving my comment here as well for increased visibility:

Current state of things:

- React is inconsistent

- API is camelCase

Proposed state of things:

- React is inconsistent

- API is camelCase

- `className` -> `class`

Perceived benefits:

> If React was open sourced today, it seems like the pros of allowing class (closer conceptually to what most people expect, less typing for the most commonly used prop) outweigh the downsides (slightly more typing to intercept it — in which cases you'll probably just want the spread operator anyway).

Actual downsides:

- the entire ecosystem that depends on `className` stops working (huge upgrade effort)

- the entire vast body of books, tutorials, examples, code, posts, articles becomes ever so slightly invalid

- the only valid JS remaining is additional typing: `const {class: cls} = props`. Every other possible use-case in plain JS becomes invalid

- React API remains inconsistent, and breaks further assumptions (why `htmlFor` not `for` etc.)

If I were a product manager, my immediate reaction to the change would be: wat?

[danabramov]

It will be fully consistent if we change `for` too (and a couple of rare SVG attributes).

[dmitriid]

So, with `for` you will introduce even more JS-incompatibility, break even mire stuff (basically, all forms), and the reason for the change is?.. Somewhat less typing (which is already covered by autocomplete in everything but Windows Notepad)?

[danabramov]

onChange is going to affect forms anyway. So it’s not like this code wouldn’t need to be revisited.

[chrisweekly]

Highly recommend reading Dan's reasoning; it makes a lot of sense. This quote is as close as I can get to distilling it:

>"I think this is the primary reason it's desirable for props like tabIndex, cellSpacing, and most other DOM-related props to follow the camelCase convention. It's not because they're DOM property names. It's because they often end up in component APIs. And we want component APIs to be consistently camelCase."

[wLMeOv2qjsFOjZG]

But both class and className are camelCased.

[chrisweekly]

I don't understand the "but" in your uncontroversial comment.

[wLMeOv2qjsFOjZG]

It seemed to me that the paragraph you quoted does not much illuminate why one should choose for one or the other.