Feature Proposal: className can be an array of class names strings

[kareemsalah227]

Description

The current className prop on any JSX element takes only a string, that is supposed to be the class name to add to the corresponding element. This prop expects a string which makes it very easy to attach a single class name to the element.

For example:

<div className="my-css-class-name"></div>

Problem

The limitation I ran into while using className, is when I wanted to attach a couple classes to the same element, I naturally tried to do something like this:

<div className={"my-css-class-name", "my-other-css-class-name"}></div>

But unfortunately it didn't work, I then realized that it's not possible with the current JSX specification.

The proposed solution in the FAQ link I shared above suggests manually attaching the strings and add a space, or use another package called "Classnames".

Feature Proposal

I as a react user, expected naturally that I could provide multiple classes with JSX, so I think it can be useful for other developers, if the prop className can take an array of strings (classes) and does a simple Array.join(" ") in this case. So that developers won't have to join them manually or use the other package "Classnames". I believe this could be beneficial for the simple use case, and also for a more advanced use case like mine (using Material UI's makeStyles).

I would appreciate your thoughts on this suggestion. Furthermore, if discussion concludes that you agree to adopt such change, I would be more than happy to contribute it, as by chance I was looking at the beginner-friendly issues for contributors a couple days ago and couldn't find something (they're all assigned).

[kachkaev]

Looks like a duplicate of #3138. Another similar proposal: #16705.

One of possible solutions is to use classnames package:

import classNames from "classnames"

// ...

<div className={classNames("my-css-class-name", "my-other-css-class-name")}></div>

📖 classnames → Usage with React.js

[kareemsalah227]

@kachkaev Thanks a lot!

I do use classNames currently for this. I still think though that if className can take an array, then it could be beneficial in some cases. However, it's nothing critical not it is a must, so please feel free to close the issue, if you are interested in an example explaining why I think it's beneficial, then feel free to continue reading.

For example, if I am building a modal component library that people will use in their React apps, and I'm rendering a backdrop element for this modal when it's open. In order to make this modal component flexible for library users, the flexibility of styling the backdrop should be considered.

What if developers want to add "some classes" to the backdrop to customize the style? I, as the modal package developer, don't know how many classes they're going to send in props. So I'll either use classnames internally, or let the developer do it on their side and just expect a class name string. If the developer do it on their side, it might result in a repetitive pattern if they want to use the modal in other places with a different style to the backdrop, and the pattern will be repetitive across other projects.

Thus, it looks to me beneficial if prop className could accept an array, no need for developers to fetch a new package (e.g. classnames), or process classes in their code (array.join or whatever), and the code will look more cleaner I guess.

In other words, I think className should naturally also accept an array, as I think it's probably a common use case.

[bvaughn]

This has been proposed and considered a few times (#1198, #3138, #9263, #10271, #16705).

I think the closest it has come to a consensus was with the addition of a new classList property (#13828) which would correspond with Element.classList.

That would introduce some ambiguity problems though which would need to be addressed, which is why one of the most recent discussions about it ended with a suggestion to file an RFC that detailed how the edge cases would be resolved.

I'm going to close this issue for now since I don't think it adds anything new that hasn't already been discussed. An RFC would still be the right next step. In the meanwhile, the classnames package is very small so it's probably a pretty decent fallback plan. 😄

[Ark-kun]

meanwhile, the classnames package is very small so it's probably a pretty decent fallback plan.

I've checked the code and I do not see any escaping of space characters. Are you sure the library works correctly?