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?
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)?
> Migrate from onChange to onInput... It has been confusing that React uses a different event name for what's known as input event in the DOM.
This change is at least somewhat warranted, as it makes things more consistent with the DOM.
What are the reasons for `className->class`, `htmlFor->for` besides the "it's longer to type" when the many downsides to the decisions have been spelled out in no uncertain detail in the issue?
It can't be "We're already allowing passing class down to the DOM node in React 16" because you're confusing a bad decision (allowing `class`) with requirements for the change ("we now have to change className to class"). Honestly, the whole className->class lacks any real justification.
So yes, to quote yourself:
> using a React component should feel like idiomatic JavaScript.
Idiomatic Javascript is:
- no reserved words as variable names (`class` and `for` are reserved words)
- className, htmlFor etc. because that's what they are in Javascript
- in your insistence that everything needs to be camelCase you forget that `className` and `htmlFor` are already camelCase
So the main issue you seem to have is this:
> React Is Not Just Setting Properties
^ this is what causes all the problems, and this is what needs to change. Not additional confusion where "idiomatic Javascript" somehow ends up having to use reserved words and workarounds for those reserved words.
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?