Canāt say I havenāt thought of it more than a few times
I was thinking along the lines of more of a āstyled componentsā approach like grid="cols-2 justify-end gap-2" and so on, but ultimately decided ānahā. But then again⦠maybe.
EDIT
Oh wait, I missed <.grid which yes, thatās far more of a styled components approach.
The company I used to work for does have a design system in React that is very close, though a lot of the āvaluesā took their own values (like for example). Itās based off of styled system.
I think accepting any bare attribute as a class is pretty iffy. I was thinking this could better suited to more of explicitly defining what attributes are style attributes. A few special ones could have their own components too, like in your example:
ā¦and then of course youād have to have <.box> or something for <div>s. I guess really you would need a componentized version of most or maybe all dom elements (though slots could get rid of a bunch of them probably).
Anyway, then the values could just map to tailwind classes, or possibly even another CSS frameworkās classes.
Anyway, Iām just thinking out loud as I have thought quite a bit about it in the past but itās been a while, so sorry if Iām not being clear or even making any sense.
Iād suggest taking a step back and ask yourself if changing the syntax for how to apply css is actually useful. In my opinion thereās not much use in that. Iād rather look into actual higher levels of abstraction, like e.g. presented on https://every-layout.dev/.
Also Iād worry thereās pitfalls for LVs change tracking with the approach youāre taking there.
Do not quite get what the difference to class="cols-2 justify-end gap-2" is here�
that looks funky!
Yeah though about that. But Iād need way more experience to find right attributes, in my brutal approach there is no need for this.
The main reason I did that in the first place was because I can. But then I noticed that I like it.
It brings a little order in the tailwind stew (loving tailwind! but stillā¦) without losing any of its flexibility. (For more involved classes that are not valid attribute-names one could add an explicit class attr).
Will do.
I was bitten by that some time ago and thought I understood whats going on, canāt see what would be the problem hereā¦!?
Maybe not for change tracking, but afaik using this essentially means the LV has no means of splitting the static content of a template from the dynamic parts, which is used to optimize diffs by not sending the static parts again.
I think the crux of why I didnāt dive into even really trying this is because we shouldnāt really be repeating ourselves with Tailwind. The āmessinessā of Tailwind is usually relegated to single components (and can be organized by type over multiple lines). I try to have as few Tailwind classes as I can in LiveViews or dead view files, so getting rid of the class attribute didnāt feel like a giant win.
Thinking about this some more I might actually be wrong here. This static vs dynamic part is likely done at runtime, where using the a dynamic component wouldnāt really be different to a compile time known one.