How to design Reusable UI Components

[neuronishad]

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 -

@Button(templ.Attributes{"hx-post": "/login"}) {
    Login
}
// or
@Button(hx-post="/login") {
    Login
}
// or
script login() { console.log("logging in ...") }
@Button(onclick=login) {
    Login
}

[Oudwins]

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:

templ Button(attrs templ.Attributes) {
    <button type="button" {attrs...} >
    {children...}
    </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.

[leandergangso]

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.

func parseButtonAttrs(attrs templ.Attributes) templ.Attributes {
  if attrs == nil {
    attrs = make(templ.Attributes)
  }

  defaultVal := "console.log('default action on input')"
  val, ok := attrs["onclick"].(string)
  if ok {
    attrs["onclick"] = val + ";" + defaultVal
  } else {
    attrs["onclick"] = defaultVal
  }
}

// usage
templ example() {
  <button
    { parseButtonAttrs(attrs) }
    class=""
    // other attrs here
  >my btn</button>
}

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?

[AlexanderArvidsson]

I also stumbled across this issue:

This causes attribute collision and only the first instance of these attributes took effect.

Coming from a React background, this feels very foreign to me. In React, only the last attribute is used, not the first.
So Templ is actually doing the opposite.

I'd love to hear if this is intentional or just a "happy little accident", @a-h :)

[leandergangso]

In React, only the last attribute is used, not the first.

That's probably just a React thing.
The reason for this behavior is not templ, but HTML and browser defaults.
By default most browsers usually ignores equal attributes after the first occurrence.

Sidenote:
By putting { attrs... } at the start or end of the attributes on an element, you can choose if you want the attrs to take precedence over predefined attributes for that element.

[AlexanderArvidsson]

@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.

[swetjen]

I've been thinking about this too and started writing how a @button() component might work.

package button

type style map[string]string

const defaultVariant = "bg-primary text-primary-foreground hover:bg-primary/90"
const destructive = "bg-destructive text-destructive-foreground hover:bg-destructive/90"
const outline = "border border-input hover:bg-accent hover:text-accent-foreground"
const secondary = "bg-secondary text-secondary-foreground hover:bg-secondary/80"
const ghost = "hover:bg-accent hover:text-accent-foreground"
const link = "underline-offset-4 hover:underline text-primary"

var variants = style{
	"defaultStyle":     defaultVariant,
	"destructive": destructive,
	"outline":     outline,
	"secondary":   secondary,
	"ghost":       ghost,
	"link":        link,
}

const defaultSize = "h-10 py-2 px-4"
const sm = "h-9 px-3 rounded-md"
const lg = "h-11 px-8 rounded-md"
const icon = "h-10 w-10"

var sizes = style{
	"defaultSize": defaultSize,
	"sm":          sm,
	"lg":          lg,
	"icon":        icon,
}

var variant = defaultVariant
var size = defaultSize

templ Button(params ...string) {
	for _, param := range params {
		desiredVariant, ok := variants[param]
		if ok {
			variant = desiredVariant
			continue
		}

		desiredSize, ok := sizes[param]
		if ok {
			size = desiredSize
			continue
		}
	}

    <button type="button" class={fmt.Sprintf("%s %s", variant, size)}>{ children... }</button>
}

With that API, a button could work like this:
@Button() { <span>Click Me</span> }
@Button("sm", "outline") { <span>Edit</span> }

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, disabled could be captured, if passed, and assigned to the tag.

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 desiredVariant, ok := variants[param] as HTML instead of Go code. My assumption is that this is a limitation with Templ.

[Oudwins]

@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:

1. As it is currently implemented we would have to add an if check and a default value for each button attribute (not given in your example but we would need the type attribute, all the aria attribute, etc). Which can get pretty unmanageable if we have to do it for every HTML element (at least compared to react's prop spread).

2. Personally, coming from js, I am not willing to give up autocomplete. I think its essential. I am too stupid to always right "sm" rather than "small" or some other shit. Plus it allows the code completion to somewhat document the library.

Personally the way I decided to implement this for myself is like this, it gives up defaults in exchange for autocomplete/typesafety

package ui;

var buttonvariants = variants{
	variantdefault:     "bg-primary text-primary-foreground hover:bg-primary/90",
	variantdestructive: "bg-destructive text-destructive-foreground hover:bg-destructive/90",
	variantoutline:     "border border-input bg-background hover:bg-accent hover:text-accent-foreground",
	variantsecondary:   "bg-secondary text-secondary-foreground hover:bg-secondary/80",
	variantghost:       "hover:bg-accent hover:text-accent-foreground",
	variantlink:        "text-primary underline-offset-4 hover:underline",
}

var buttonsizes = sizes{
	sizedefault: "h-10 px-4 py-2",
	sizesm:      "h-9 rounded-md px-3",
	sizelg:      "h-11 rounded-md px-8",
	sizeicon:    "h-10 w-10",
}

templ button(v variant, s size, attrs templ.attributes) {
	<button type="button" class={ "inline-flex items-center justify-center whitespace-nowrap rounded-md text-sm font-medium ring-offset-background transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 disabled:pointer-events-none disabled:opacity-50", buttonvariants[v], buttonsizes[s] } { attrs... }>
		{ children... }
	</button>
}

Sizes & variants are enums

package ui

type Variant int

const (
	VariantDefault Variant = iota
	VariantDestructive
	VariantOutline
	VariantSecondary
	VariantGhost
	VariantLink
)

type Variants map[Variant]string

type Size int

const (
	SizeDefault Size = iota
	SizeSm
	SizeLg
	SizeIcon
)

type Sizes map[Size]string

[Oudwins]

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...

[tylantz]

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.

[Oudwins]

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?

[tylantz]

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.

[Oudwins]

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.

[tylantz]

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.

[eikster-dk]

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?

@Button(htmx.Post("/login").Swap("outerHTML").Target("this")) {
    Login
}

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.

[alexferl]

I've also been thinking about how to design reusable components.
I personally use Flowbite and was thinking to model the components similar to their React lib:

components/badge/badge.go:

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()
}

components/badge/badge.templ:

package badge

templ Badge(p *Props) {
	<span class={ p.className() } { p.Attrs... }>{ children... }</span>
}

components/badge/theme.go:

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",
			},
		},
	}
}

main.go:

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)
}

main.templ:

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.

[Oudwins]

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.

[AlexanderArvidsson]

Damn, I just wasted yesterday doing the exact same thing, converted the tailwind-merge JS / Ruby library to Go for use in Templ.
Good job man! 🥇

[Oudwins]

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

[AlexanderArvidsson]

@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 VariantOption the same way you usually do for the key in context instead of strings, so you must pass in a type of ButtonVariant or ButtonSize which forces you to utilize those structs to provide auto-completion. Strings would make developers lazy and avoid the type-safety, resulting in undesirable bugs if the variants change.

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!

[Oudwins]

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!

[RafaelZasas]

I think the best way to do it is to separate the functional logic from the styling as much as possible.
When it comes to tailwind, its very easy to create custom classes based on tailwind classes as such:

@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 btn-primary class to it. ANY element could "be a button" for that matter.

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.

[RafaelZasas]

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.
You can always sprinkle in extra tailwind class names on top of your existing custom ones and even throw a !important in there to avoid conflicts.

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.

[Oudwins]

@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)

[RafaelZasas]

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:

If you’re going to use @apply, use it for very small, highly reusable things like buttons and form controls — and even then only if you’re not using a framework like React where a component would be a better choice.

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.

[Oudwins]

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

[Oudwins]

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....

[fravan]

Hi there, I am reading this discussion from time to time thinking about reusability.
I started with basic classes on html elements (button, input, using @apply which I am not a strong fan of), and then a colleague of mine talked about Class Variant Authority.

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 CompoundVariants ?

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")
}

button is a function that returns the class to apply, based on given variant that are defined with above. The CompoundVariant allows to add some custom classes when a number of variants are present.

The code of the cva package is pretty naive and as follow :

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 !
Cheers.

[Oudwins]

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?

[fravan]

Unfortunately, it doesn't.

I was thinking of making my components into individual packages such as ui/buttons/files.go with package named buttons, and have from there the name of the different variant exported.
Something like class={ buttons.Get(buttons.Primary, buttons.Medium) }, with Get the function returned by the cva package.

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 type Variants = 'primary' | 'secondary' but did not find it. I don't know Go Generics well enough to be able to have some kind of constraint such as K extends keyof MyVariantDefinition. So in term of advantage / inconvenient, it is very much the same as your approach.

[maltegrosse]

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

templ (g *group)inputNumber(label string, name string,id string, value string, required bool, inputAttributes templ.Attributes) {
	<div class="pf-v5-c-form__group">
		if len(label)>0 {
			<div class="pf-v5-c-form__group-label">
				@Label(label,id,required)
			</div>
		}
		<div class="pf-v5-c-form__group-control">
			<span class={"pf-v5-c-form-control",templ.KV(required,"pf-m-required")}>
				<input value={ value } required="" type="number" id={ id } name={ name } data-loading-disable { inputAttributes... }/>
			</span>
		</div>
	</div>
}

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)
That means an input field is package private, and a NewFormGroup is public. Using then struct methods and returning the form group as a pointer helps me to pipe components like:

f := forms.NewFormGroup(false, formAttributes)
f.AddTextInput("ID", "id", "", user.ID, false, templ.Attributes{"disabled": true})
f.AddTextInput("Username", "username", "", user.Username, true, nil).AddTextInput("Email", "email", "", user.Email, true, nil)
...

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)

type button struct{
	name string
	classes []string
	attributes templ.Attributes
	btnType string
	loader templ.Component
	level buttonLevel
}
func NewPrimaryButton(name string, isSmall bool, level buttonLevel, attributes templ.Attributes)*button{
	b := button{name: name,attributes: attributes, btnType: "button"}
	b.classes = append(b.classes, string(Primary))
	b.classes = append(b.classes, string(level))
	if isSmall{
		b.classes = append(b.classes, small)
	}
	return &b
}
func (b *button)AddClass(class string)*button{
	b.classes = append(b.classes, class)
	return b
}

Additionally, public interface could be helpful , e.g.

type Button interface {
 AddAttributes(templ.Attributes)
 Component()templ.Component
}

type someButton struct{
 Button

}
func NewSuperButton(someinit string)*someButton{
return &someButton{...}}

thus a formgroup could have something like

(g *group)AddActionButtons(...btns Button) //Add submit and cancel/clear button

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":

func (h *Handler) UserForm(w http.ResponseWriter, r *http.Request) {
	userTypes, err := h.useCase.ListUserTypes(r.Context(), filter.NewFilter()) // something from application logic/db
	if err != nil {
		alert := h.composer.CreateToastErrorAlert("Error", err.Error(), h.htmx.NewHandler(w, r))
		alert.Render(r.Context(), w)
		return
	}

	h.composer.CreateUserFormModal("Create User", userTypes, h.path).Render(r.Context(), w)
}

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...)
The good thing about golangs strict error handling is that u need to consider all that cases :-)

[a-h]

This looks really great. It also prompted me to write #663