Typed Variant & Compound Variant Proposal #256
Replies: 3 comments 9 replies
-
|
I think I want to revisit the infrastructure to make it more 1:1 with tailwind-variants if possible, while maintaining type-safety |
Beta Was this translation helpful? Give feedback.
-
|
Hey @Denny09310, Good stuff! I spent quite a bit of time trying to figure out the best approach. I also tried the Fluent API, but even though it gives you a fully typed API, I found it loses readability compared to the tailwind-variants structure. Since I didn’t want to slow myself down when copying styles, I chose a more readable, similar API over a fully typed one. That said, I always planned to revisit this at some point. Really nice that you decided to dive deep into it! I like what you have so far! I have a couple of suggestions/concerns:
|
Beta Was this translation helpful? Give feedback.
-
|
I think I’ve got it figured out. I ended up rewriting the entire infrastructure, and now it’s almost identical to the original—about a 1:1 match. It’s still a work in progress: I need to verify everything works, split it into separate files, and add tests. But for now, I’d like your feedback specifically on the syntax inside the demo. The branch is refactor/tw-variants. When you have time obviously 🙂 I realize some of the same issues as before might still be present. However, I believe I’ve reduced the evaluations, and overall, I think I’ve made some improvements. Edit: I'm experimenting with a source generator to avoid multiple Expression evaluation, I'm pretty satisfied. It could benefit some improvements, but for now it does the job. The branch is feature/slots-source-generator if you are interested in the option. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I’ve been experimenting with a typed approach to handling variants and compound variants in Blazor. LumexUI already has a similar system, but this version aims to bring stronger typing and safer defaults while keeping flexibility.
I also want to be transparent: I used a bit of AI help to shape the design and documentation, but the implementation and direction come from real-world experimentation.
Curious to hear your thoughts: would a typed API like this be worth exploring for LumexUI, or should we keep the current dynamic approach?
This is the gist with the implementation and a button example. It could be a startI've created a github repository, from which I'd like to expand to a nuget package. Watch this to review the structure instead of the gist 😁
Edit: I've realized now that I'm missing a big portion of the infrastructure, as for now I can't make a variant for more than one slot at a timeBeta Was this translation helpful? Give feedback.
All reactions