The short, unsatisfying answer is that using `class` is deprecated in React, and has been for a while.
For a longer answer, take a look at the discussion of issue #4433 on github [1], especially the following comment by spicyj [2]:
> [...] We're sticking with className and htmlFor for a couple of reasons:
> First, we tend to look at HTML properties (like el.className = ...) when possible, as opposed to attributes (like el.setAttribute('class', ...)). Attributes are always string-typed, while properties can have any JavaScript object value, which gives more flexibility in some circumstances. One example is the .classList property, which arguably is a better fit for the data model than .className is. React doesn't support classList right now, but it certainly could. Given that React's className behaves like the HTML property of the same name, it makes sense to keep that name.
> Another reason is more forward-thinking. In the future, idiomatic React may use object destructuring to pick apart this.props. The react-future repo shows one example of how this could work. Even in modern browsers, this wouldn't work with class and for which are keywords and can't appear as standalone identifiers even though they can appear as property names.
> Third, our thinking is that JSX's primary advantage is the symmetry of matching closing tags which make code easier to read, not the direct resemblance to HTML or XML. It's convenient to copy/paste HTML directly, but other minor differences (in self-closing tags, for example) make this a losing battle and we have a HTML to JSX converter to help you anyway. Finally, to translate HTML to idiomatic React code, a fair amount of work is usually involved in breaking up the markup into components that make sense, so changing class to className is only a small part of that anyway.
For a longer answer, take a look at the discussion of issue #4433 on github [1], especially the following comment by spicyj [2]:
> [...] We're sticking with className and htmlFor for a couple of reasons:
> First, we tend to look at HTML properties (like el.className = ...) when possible, as opposed to attributes (like el.setAttribute('class', ...)). Attributes are always string-typed, while properties can have any JavaScript object value, which gives more flexibility in some circumstances. One example is the .classList property, which arguably is a better fit for the data model than .className is. React doesn't support classList right now, but it certainly could. Given that React's className behaves like the HTML property of the same name, it makes sense to keep that name.
> Another reason is more forward-thinking. In the future, idiomatic React may use object destructuring to pick apart this.props. The react-future repo shows one example of how this could work. Even in modern browsers, this wouldn't work with class and for which are keywords and can't appear as standalone identifiers even though they can appear as property names.
> Third, our thinking is that JSX's primary advantage is the symmetry of matching closing tags which make code easier to read, not the direct resemblance to HTML or XML. It's convenient to copy/paste HTML directly, but other minor differences (in self-closing tags, for example) make this a losing battle and we have a HTML to JSX converter to help you anyway. Finally, to translate HTML to idiomatic React code, a fair amount of work is usually involved in breaking up the markup into components that make sense, so changing class to className is only a small part of that anyway.
----
[1]: https://github.com/facebook/react/issues/4433 [2]: https://github.com/facebook/react/issues/4433#issuecomment-1...