-
-
Notifications
You must be signed in to change notification settings - Fork 303
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
proposal: cumbersome css class API. #61
Comments
In https://reactjs.org/docs/faq-styling.html React recommends this package to deal with the same sort of problem - https://www.npmjs.com/package/classnames#usage-with-reactjs |
It looks like to implement that in templ, it would require Or continue with the implementation we have now but use import . "github.com/a-h/templ"
css customClass() {
background-color: black;
}
templ Template() {
<span class={Classes(Class("c1"), Class("c2"), Class("c3"), Class("c4"), customClass())}></span>
} |
Hi, any progress on this? I'm in a similar situation with many small classes. I'm now using this cumbersome helper (is there an alternative way?):
|
No, haven't made any progress on this. I wanted to decide the best way to proceed in terms of design. I'm thinking that allowing multiple class attributes might be the best way, and would fit with allowing if statements in the attribute list as per #65
|
Absolutely! And once that's done (see branch linked above), the syntax is a lot less verbose.
To do optional attributes, you can use a map expression, which is a bit ugly, but in the branch above it works.
The
Thoughts? |
This is looking much cleaner for more complex cases. The last example could be useful but could also be prone to developer error. I wonder if we could use generics some way to constrain what can be entered at compile time. If not I suppose there's the benefit that this code passes through the templ generate command, so the command could error if the wrong types are passed in. |
I don't think there's a way to constrain with generics without proper union types. I have updated the syntax in the branch above to support an even less verbose mechanism at the cost of reduced type safety in the class Go expression. Because the So now, instead of:
You can now do this. In addition, the previous syntax is still supported.
Since in Go, iterating map keys is not ordered by insertion, I've ordered the keys in
I've also added a KV type which can be used instead, which ensures order:
I think there's one more change to go... in that it's possible to forget to call a templ CSS expression as a function, for example, here, I've missed the brackets.
In this case, the CSS class handling code needs to call the function too. |
Right, I think that's it. Once this PR is merged, you can do this...
|
I've been using templ to build some web pages, and am using bulma.io for styling. Most css frameworks like this work using thin css classes, so it's not strange to have around 5 classes on an element in some cases.
Currently the templ classes API makes it tough to do this kind of thing dynamically.
If the classes are all static then the following works:
As soon as you want to include a templ
css
class you need to usetempl.Classes
:Proposal 1 - Support 2 class attributes.
Allow strictly one static class attribute and one dynamic (this doesn't work at the moment):
Proposal 2 - Support spaces in a
templ.Class
Allow spaces in a
templ.Class
this goes against the type as it isn't plural (this doesn't work at the moment):Proposal 3 - Create an alternative to
templ.Classes
that takes a string as first parameter.A new function that supports static classes as a string then variadic
templ.Class
.The text was updated successfully, but these errors were encountered: