-
Notifications
You must be signed in to change notification settings - Fork 414
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Class name composition is harder than it needs to be #601
Comments
I don't see a way to improve this.
|
How is it not special if Reagent converts To be clear - I'm not saying that Reagent components should start seeing |
We only convert From your example it wasn't obvious to me in which step the additional conversion should happen. We to convert the https://github.com/reagent-project/reagent/blob/master/src/reagent/impl/util.cljs#L129-L137 Maybe it would be possible to extend this with additional |
Of course. I think React components are free to treat
I started writing an answer to that before noticing that you've said it yourself at the bottom:
Exactly. So maybe the 1-arg arity can be something like ([class]
(cond
(named? class) (name class)
(coll? class) (string/join " " (map class-names class))
:else class)) |
An example of what IMO the usage should end up with:
Currently, this results in the class being ultimately set to
"child [:parent :grandparent]"
.So the users have to use
r/class-names
every single time they need to combine classes:Not too harde but harder than it can be.
Another problem with that approach is that the data is composed prematurely. When the "stringification" happens at the very edge of the rendering, the user code can still the full
:class
data structure as it was created by the app, including all the collections, keywords, strings,nil
s. Seeing that definitely helps with debugging. It also enables class collection preprocessing in some child component, although I'm hesitant do deem this particular usage as viable.The text was updated successfully, but these errors were encountered: