How to design Reusable UI Components #432
Replies: 11 comments 23 replies
-
|
I am also very interested in this. It is not only useful for htmx but for making reusable ui components in general. For example for a button: If we want to be able to add a value to the type attribute we have to add another required argument or just use the templ.Attributes which is not typesafe and ??there is no way to add default values?? Additionally I will say that to be able to make reusable components for public use (which is also something I was thinking about) if we were to make something inspired by shadcn using tailwindcss we would need to port tailwind merge to golang. Otherwise we can have style conflicts. |
Beta Was this translation helpful? Give feedback.
-
|
I'm a bit late here, but wanted to comment on the "no default attrs". I recently had an issue with having an attr on a component, that I also added in attrs prop. This causes attribute collision and only the first instance of these attributes took effect. My solution to this, add well as possibility for default values, was to wrap the attrs in a func call, see example code below. Are perhaps cleaner solutions, but this has been working for me. Note for better dx, could possibly create custom attrs struct with the most common attrs, then map those into the templ.Attributes, to setup defaults, overwrites, or other? |
Beta Was this translation helpful? Give feedback.
-
|
I also stumbled across this issue:
Coming from a React background, this feels very foreign to me. In React, only the last attribute is used, not the first. I'd love to hear if this is intentional or just a "happy little accident", @a-h :) |
Beta Was this translation helpful? Give feedback.
-
That's probably just a React thing. Sidenote: |
Beta Was this translation helpful? Give feedback.
-
|
@leandergangso I'd argue it's a Javascript thing, since it follows the object definition precedence. Since JSX props are ultimately deconstructed into objects, the last defined key always wins. I didn't consider that HTML actually allowed multiple attributes. If HTML always respects the first one, then that would make React the odd one out since they're following Javascript. So I agree, Templ is doing the right thing here and following how it works in HTML! But as I believe a lot of React developers go to Templ (since it's the closest), I believe it might be worth putting an info box in the documentation how the ordering works. Even though it follows HTML standard, HTML does not have spread attributes, which makes this a case that might benefit from some extra documentation. |
Beta Was this translation helpful? Give feedback.
-
|
I've been thinking about this too and started writing how a @button() component might work. With that API, a button could work like this: Seems reasonable to me. Go's spread operator does a nice job accepting a variable number of parameters. Of course this requires that parameter names are unique but I think that tradeoff would probably be okay. Especially since the 'default' cases are the defaults. This pattern could pretty easily be extended to handle other attributes. For example, I deliberately left the HTMX params off this component so that it could be used in different contexts. I agree with @Oudwins that components are better left generic. That way, a form is welcome to implement its own submit handler. And if I want this Button to link somewhere I could just wrap it in a tag. The first roadblock I ran into is that the this is not a valid Templ component. Templ renders the |
Beta Was this translation helpful? Give feedback.
-
|
@swetjen Thats very interesting! You managed to get defaults working but at the cost of typesafety & autocomplete. I think this is something that could definitely work. And be acceptable for many. I there are a few drawbacks I see though:
Personally the way I decided to implement this for myself is like this, it gives up defaults in exchange for autocomplete/typesafety Sizes & variants are enums |
Beta Was this translation helpful? Give feedback.
-
|
As far as support for library devs on the templ side I think some kind of function to handle conflict resolution for attributes might be the way to go. Providing a hook at ??a component level??? that allows you to pick which attributes to keep (or to merge them) when there are multiple of the same type (i.e merge them if two class or style attributes but ignore the first if two type attributes). This would solve the issue that I posed in my first message where if I set a default value for an attribute it cannot be replaced with a value from templ.Attributes. But would not solve the problem if autocomplete/typesafety... |
Beta Was this translation helpful? Give feedback.
-
|
I agree that merging attributes is important. I could see an implementation in which one passes a value and an update function for each attribute with a set of standard update functions (e.g., append, replace, replace if empty, etc.) and the ability to pass custom functions. The question is how do you do it in a type-safe way that doesn't make for a very messy API -- there are well over 100 html element attributes. For my usecase (styling with tailwind), class is the most important attribute to merge, but it is also the most complicated to merge correctly. For that reason, I wrote go-tailwind-merge to merge classes intelligently. It is similar in spirit to the typescript package, tailwind-merge, which is used by shadcn-ui and all of it's framework ports, but this version has a different implementation. @Oudwins, you might find it useful. |
Beta Was this translation helpful? Give feedback.
-
|
I literally spent a few hours yesterday looking at the TS implementation and heavily considering porting it to go. So you just saved me a bunch of time. Thank you so much! Will this really be faster than doing it the way tailwind-merge does it? Why? |
Beta Was this translation helpful? Give feedback.
-
|
No problem. I saw your comment last week and I needed it too. Luckily I could use most of the tests in the JS version. I started with porting it using the their implementation, but I felt I could more accurately implement the behaviour using the CSS spec than going very deep on tailwind naming conventions. My implementation can also be used for non-tailwind classes, and it remains accurate when someone defines custom rules using tailwind names. The two approaches differ in a few ways that can affect performance. Firstly, they use a very large configuration file that is used to find conflicts. Shipping this file to the client can add to your page-load times (when used in JS-land), but presumably sending it to the client wouldn't be necessary for SSR with go. The primary difference is they lexicographically decompose each class name into the components that make up a tailwind class name, for instance, md:hover:p-2 gets split into md for screen size, hover for hover state, p-2 for padding, and then each part is analysed for conflicts using the configuration file. They use regex to do this analysis, which can be slow. I also think they compare each class to one another so their implementation is O(n^2) -- I'm not 100% sure about this though. In contrast, my implementation parses the rules once, and then the class name resolution is almost entirely map lookups. My implementation essentially keeps the class that provides the last definition of a CSS property, so it is O(n). Both implementations can cache results so after the first time a class attribute is merges, performance differences are negligible. |
Beta Was this translation helpful? Give feedback.
-
|
No they don't compare each class with one another. They use hash map look ups also (at least from what I saw). I am not sure, but I would think that comparing the entire stylesheet would be slower than breaking each class into its components and seeing if there are collisions like they do it. But maybe not. I'll consider porting their implementation and maybe we can compare running times. |
Beta Was this translation helpful? Give feedback.
-
|
That's good to hear. The merger in go-tailwind-merge parses the whole stylesheet only once at initialisation. Then, on merges, it only compares the rule definitions associated with the classes in the given string. Look here if you're curious. Performance shouldn't be an issue either way because the results are cached. Do write back if you implement it, I'd be curious to see your code. |
Beta Was this translation helpful? Give feedback.
-
|
I'm also playing around with the idea of building reusable components where I want HTMX for buttons, input fields etc and after reading this I got the idea that maybe a builder pattern could be used to support the wish of having something that is typesafe and hints from the LSP's I haven't made any POC on it yet but I'm going to play around with the idea this week. I wonder if something like this could support the various use cases for both css classes and htmx? The same idea could potentially be applied to the CSS stuff related to different variation of buttons and styles. I wonder if it will end up becoming too verbose and you would have to maintain the builders as well. Semantically it looks more intuitive when I have to use the different components, even tho it puts a burden on the component maintenance of keeping the builders up to date etc. Anyhow I think I'm gonna give it a try the coming days, at least for my HTMX use case and see how it will work out. |
Beta Was this translation helpful? Give feedback.
-
|
I've also been thinking about how to design reusable components.
package badge
import (
"strings"
"github.com/a-h/templ"
)
type Props struct {
Attrs templ.Attributes
ClassName string
Color string
Href string
Size string
Theme *Theme
buf *strings.Builder
}
func (p Props) className() string {
p.buf = &strings.Builder{}
if p.Theme == nil {
p.Theme = NewTheme()
}
switch p.Color {
case "default":
p.buf.WriteString(p.Theme.Root.Color.Default)
default:
p.buf.WriteString(p.Theme.Root.Color.Default)
}
p.buf.WriteString(" ")
switch p.Size {
case "xs":
p.buf.WriteString(p.Theme.Root.Size.Xs)
case "sm":
p.buf.WriteString(p.Theme.Root.Size.Sm)
default:
p.buf.WriteString(p.Theme.Root.Size.Xs)
}
p.buf.WriteString(" ")
if p.ClassName != "" {
p.buf.WriteString(p.ClassName)
}
return p.buf.String()
}
package badge
templ Badge(p *Props) {
<span class={ p.className() } { p.Attrs... }>{ children... }</span>
}
package badge
type Theme struct {
Root
}
type Root struct {
Color
Size
}
type Color struct {
Default string
}
type Size struct {
Xs string
Sm string
}
func NewTheme() *Theme {
return &Theme{
Root: Root{
Color: Color{
Default: "bg-blue-100 text-blue-800 font-medium me-2 px-2.5 py-0.5 rounded dark:bg-blue-900 dark:text-blue-300",
},
Size: Size{
Xs: "text-xs",
Sm: "text-sm",
},
},
}
}
package main
import (
"fmt"
"net/http"
"github.com/a-h/templ"
)
func main() {
http.Handle("/", templ.Handler(Main()))
fmt.Println("Listening on :4000")
http.ListenAndServe("127.0.0.1:4000", nil)
}
package main
import "flowbite-templ/components/badge"
func getProps() *badge.Props {
theme := badge.NewTheme()
theme.Root.Size.Xs = "text-lg"
props := &badge.Props{
ClassName: "foo bar",
Attrs: templ.Attributes{"disabled": true, "hello": "world"},
Theme: theme,
}
return props
}
templ Main() {
<div>
@badge.Badge(getProps()) { Default }
</div>
}Output: <div><span class="foo bar bg-blue-100 text-blue-800 font-medium me-2 px-2.5 py-0.5 rounded dark:bg-blue-900 dark:text-blue-300 text-xs" disabled hello="world">Default</span></div>Can also be simplified if you don't need to modify the theme: package main
import "flowbite-templ/components/badge"
templ Main() {
<div>
@badge.Badge(&badge.Props{ClassName: "foo bar", Attrs: templ.Attributes{"disabled": true, "hello": "world"}}) {
Default
}
</div>
}The one thing that's missing is something that works like tailwind-merge in Go. I currently hacked it up with v8go, but that's obviously not ideal. |
Beta Was this translation helpful? Give feedback.
-
|
Its done, its at -> https://github.com/Oudwins/tailwind-merge-go I'll start actively using this in for a project next week to see if there are any issues but so far all tests are passing without problem. |
Beta Was this translation helpful? Give feedback.
-
|
Damn, I just wasted yesterday doing the exact same thing, converted the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! @AlexanderArvidsson care to share your implementation? I would love to look through your code see if there is any improvements I can make to the library. I'm also 100% open to any ideas you might have to improve the current implementation. I got the project listed in the official tailwind merge github under similar projects. Hopefully that helps other people find it and we can avoid duplicating too much work |
Beta Was this translation helpful? Give feedback.
-
|
@Oudwins I was about to turn it into a package, I only had the last part with extending configs left (which I believe you've left out as well?). If you want, you could add me on Discord, since I would also like to brainstorm around the CVA approach suggested here as well! Let me know and I'll send you a temporary email you can contact me on :) @fravan I've made a variation of your CVA that allows for a very flexible and "type-safe" way to define reusable components without too many ugly hacks. It uses reflection to get the list of valid variants from the structs you define of possible variants. Then, those variants are validated on runtime. I'm using Here's an example: type ButtonProps struct {
Variant cva.VariantOption
Size cva.VariantOption
Attrs cva.Attributes
}
type buttonVariants struct {
Primary cva.VariantOption
Secondary cva.VariantOption
}
type buttonSizes struct {
Small cva.VariantOption
Medium cva.VariantOption
}
var ButtonVariant = buttonVariants{
Primary: cva.NewVariant("primary"),
Secondary: cva.NewVariant("secondary"),
}
var ButtonSize = buttonSizes{
Small: cva.NewVariant("small"),
Medium: cva.NewVariant("medium"),
}
var button = cva.New(
"px-4 border rounded-md bg-gray-700 border-gray-600",
cva.VariantList{ButtonVariant, ButtonSize},
cva.Variant(ButtonVariant.Primary, "bg-blue-500"),
cva.Variant(ButtonVariant.Secondary, "bg-white"),
cva.Variant(ButtonSize.Small, "text-sm"),
cva.Variant(ButtonSize.Medium, "text-base"),
cva.CompoundVariant([]cva.VariantOption{ButtonVariant.Primary, ButtonSize.Medium}, "uppercase"),
)
templ Button(props *ButtonProps, attrs ...templ.Attributes) {
<button { cva.Compose(button, cva.FromProps(props), attrs)... }>
{ children... }
</button>
}And usage: @c.Button(
&c.ButtonProps{
Variant: c.ButtonVariant.Primary,
Size: c.ButtonSize.Small,
},
templ.Attributes{"onclick": "alert('hi')"}
) {
A small, primary button
}
// or
@c.Button(nil) {
Default variant
}Could probably be simplified, but it's a start! |
Beta Was this translation helpful? Give feedback.
-
|
Yes I still have the config extension on the roadmap. For sure, add me I'm also interested in the. Cva approach. My discord is just @Oudwin Your approach seems VERY nice! |
Beta Was this translation helpful? Give feedback.
-
|
I think the best way to do it is to separate the functional logic from the styling as much as possible. @tailwind base;
@tailwind components;
@tailwind utilities;
@tailwind variants;
@layer components {
.btn-accent {
@apply rounded-md border-2 border-primary-light/70 bg-accent-dark px-4 py-2
font-semibold text-surface-dark shadow-md shadow-accent-light/70
hover:bg-accent-light hover:text-surface hover:shadow-md hover:shadow-accent-dark
focus:outline-none focus:ring focus:ring-accent-dark focus:ring-opacity-75;
}
.link {
@apply font-semibold text-sky-600 visited:text-pink-800 hover:text-sky-700;
}
}This eliminates (for the most part) the need to have a dedicated templ component for a button, since an anchor tag could be a button too if you just add the The same logic could be applied to creating templ components. You can create a templ button component which contains only styles and children, and then you can use the @button component by passing in the children that contain the logic like href's or htmx attrs. |
Beta Was this translation helpful? Give feedback.
-
|
I would also like to add - By shifting the majority of the styling to custom class names, you actually make your templ (and thus html) files smaller. The css files can be aggressively cached, minified and zipped. Your html cannot. It's also a preference of mine to keep the htmx attrs on html elements. I tried passing them as args but things became a massive mess very quickly. |
Beta Was this translation helpful? Give feedback.
-
|
@eikster-dk Personally I am really against building abstractions when they only provide minimum DX improvements. Someone will have to maintain those abstractions up to date with HTMX, CSS, etc @RafaelZasas the creators of tailwind recommend against doing this. And it is, objectively bad. Specially for writing something like a component library since users won't be able to override your styles. It might seem like a cleaner way of doing it & one that generates code that is easier to minify but both ideas are actually incorrect. Checkout this video by theo that goes a little more in depth into why this is the case -> https://www.youtube.com/watch?v=yGBjXsrwK4M (there is another one that is even better but I can't find it right now) |
Beta Was this translation helpful? Give feedback.
-
|
I'm always excited to learn the idiomatic ways of using tools. Would you mind providing some references to Adam or the Tailwindcss team recommending against creating custom class names? I did find this in The documentation regarding premature abstraction:
However it seems that this is both a case of small, highly reusable things like buttons and form controls, as well as a framework without built in component support. Regarding the video, theo is cool but I prefer to base my choices on the advice of the creators of the tool. |
Beta Was this translation helpful? Give feedback.
-
|
Rereading my comment it could have sounded a little aggressive which was not my intention. I am glad you did not take it that way. There is a tweet somewhere saying that @apply was a mistake also. Either way I think the paragraph you quoted is quite clear. The component model is what works best so use that when ever you can. Which basically leaves using @apply only for weird use cases which I am not going to get into & if you are writing raw html (i.e not using any kind of templates/components). Otherwise you are better off having a component that is a button and has the styles you want. I understand templ doesn't actually make this easy because you lose out on autocomplete for your button and have to pass everything through templ.Attrs which is part of the issue we are discussing here. Either way, feel free to use @apply if you find it easier or like it more. I believe that once you have written enough tailwind you will come to appreciate that it brings more problems than it solves. But mostly I would argue you jumping into using @apply or the weird hack I have made (see below) is a problem with templ and not tailwind |
Beta Was this translation helpful? Give feedback.
-
|
Currently the best solution I have found is doing things like this func BtnBase() string {
return btnBaseCSS
}
func BtnVariant(args ...Variant) string {
switch args[0] {
case VariantDestructive:
return "bg-destructive text-destructive-foreground hover:bg-destructive/90"
case VariantOutline:
return "border border-input bg-background hover:bg-accent hover:text-accent-foreground"
case VariantSecondary:
return "bg-secondary text-secondary-foreground hover:bg-secondary/80"
case VariantGhost:
return "hover:bg-accent hover:text-accent-foreground"
case VariantLink:
return "text-primary underline-offset-4 hover:underline"
default:
return "bg-primary text-primary-foreground hover:bg-primary/90"
}
}
func BtnSize(args ...Size) string {
switch args[0] {
case Sm:
return "h-9 px-3"
case Lg:
return "h-11 px-8"
case Icon:
return "h-10 w-10"
default:
return "h-10 px-4 py-2"
}
}Then in the html/tmpl file <button class={BtnBase(), BtnVariant(), BtnSize(Sizes.Sm)} >Syntax is not pretty but it allows the use of default values & high composability. Main problem is that this doesn't work for custom components, autocompletion.... |
Beta Was this translation helpful? Give feedback.
-
|
Hi there, I am reading this discussion from time to time thinking about reusability. I started writing a very naive version of it in go to try it. I think it is similar to your approach, with maybe a little more feature with Here is what it looks like : var (
Primary string = "primary"
Secondary string = "secondary"
Small string = "small"
Medium string = "medium"
)
func TestCvaCompoundVariants(t *testing.T) {
assert := assert.New(t)
button := cva.New(
"font-semibold border rounded", // base
cva.Variant(Primary, "bg-blue-500"),
cva.Variant(Secondary, "bg-white"),
cva.Variant(Small, "text-sm"),
cva.Variant(Medium, "text-base"),
cva.CompoundVariant([]string{Primary, Medium}, "uppercase"),
)
assert.Equal(button(), "font-semibold border rounded")
assert.Equal(button(Primary), "font-semibold border rounded bg-blue-500")
assert.Equal(button(Medium), "font-semibold border rounded text-base")
assert.Equal(button(Primary, Medium), "font-semibold border rounded bg-blue-500 text-base uppercase")
}
The code of the type VariantRules func(currentValue string, options string) string
func Variant(name string, value string) VariantRules {
return func(currentValue string, options string) string {
if strings.Contains(options, name) {
return fmt.Sprintf("%s %s", currentValue, value)
}
return currentValue
}
}
func CompoundVariant(variants []string, value string) VariantRules {
return func(currentValue string, options string) string {
for _, variant := range variants {
if !strings.Contains(options, variant) {
return currentValue
}
}
return fmt.Sprintf("%s %s", currentValue, value)
}
}
func New(base string, variants ...VariantRules) func(options ...string) string {
return func(options ...string) string {
allOptions := ""
for _, opt := range options {
allOptions += " " + opt
}
result := base
for _, variant := range variants {
result = variant(result, allOptions)
}
return result
}
}I thought I would share it here, maybe it could be of interest ! |
Beta Was this translation helpful? Give feedback.
-
|
This looks very interesting and promising for making reusable components! Does this get you auto complete for the variants and throw an error at you when you provide an invalid variant? |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, it doesn't. I was thinking of making my components into individual packages such as But that does not make real autocompletion, nor does it do any check, at anytime. Coming from TS, I searched, quickly, for a way to create an enum such as |
Beta Was this translation helpful? Give feedback.
-
|
Iam trying to build some components for my daily usage based on patternfly html (not react) components. I try to make each button/label/input field as much general as possible but then mainly follow the design patterns of the framework which forces me e.g. to build a form group when using input fields. (which is good, as alot of qualified designer worked on that part) etc... The templ.Attributes still allow me to attach any specific attributes if needed (especially using htmx, as I try to avoid any js overhead) another idea is, e.g. for buttons, to add a basic struc, and init basic values via the public constructor, as the options/variants a nearly impossible to cover, you can still expose a "AddClass" method to attach more css classes if needed. (css classes are defined somewhere as constants) Additionally, public interface could be helpful , e.g. thus a formgroup could have something like Finally, I wrap everything which is used often in a general composer (e.g. create full page,create main menu,toast alerts, etc), but additional, every view/usecase/domain gets their custom composer, e.g. createUserModel, createUserTable etc... such that the handler stays quite simple and "clean": there is still alot of space to improve...and I havent figured out 100% my final structure, as especially using htmx with error handling can get abit crazy (e.g. have a modal, form,submit and save, handle input error (inside the form) if can not safe (within the modal) handle that error, close it if successful, reload table if successful, show another error if this refresh does not work etc etc...) |
Beta Was this translation helpful? Give feedback.
-
|
This looks really great. It also prompted me to write #663 |
Beta Was this translation helpful? Give feedback.
-
To continue the topic Issue: How to design Reusable UI Components. The issue here was in the context of a single project but can be generalized as how to design reusable UI components with templ for public use.
I am a fan of tailwind CSS and recently come across HTMX. I personally think that building most common web projects can be done very quickly using Go, templ, tailwind CSS, HTMX as HTMX and tailwind gives the UI utilities and templ now allows us to build components in Go itself!
Now looking at my experience (see the issue for more details) with development of this particular stack, If I were to build components which is possible when you are building in the context of single project. To elaborate, I can create a login button or Submit button where the actions/api are known before the components.
Now, to make this for public use, I won't know what actions / JS attributes will be used for a specific component, hence I need to expect everything.
One way to do this is to add all JS attributes as arguments, but then HTMX and JS arguments will be different, not all will be used, the attributes will have to follow all the new releases particularly in case of utilities like HTMX. We can see this is hard to maintain.
Another way is to use Spread Attributes feature with templ.Attributes but as I mentioned in the issue, LSP kind of fails here. Now we could update LSP to work in this scenario but is this the best approach I wonder.
Now taking a step back, one might wonder why do of all this and not write just CSS and JS. My answer to this is if you look at the current popular way allowing the community to build their own components rather than giving a rigid library is much better way of UI development. Example for this is shadcn.
The use of popular utility like tailwind css and code availability to update are the reasons why I think it's very popular. So, if we were to follow the same philosophy here, extending it to HTMX as well, it might lead to being more useful.
So, my question is how one should go about designing this, are templ.Attributes way to go, or can we do something which will allow us to use HTMX or JS attributes in components usage which seems to be more natural. Ex -
Beta Was this translation helpful? Give feedback.
All reactions