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

[Roundaround]

Hi folks!

I know this is an old thread but I recently got myself into a new project where I was hoping to design some kind of internal reusable component library. I have dabbled in the past with class-variance-authority in the React/TS world and really enjoyed that design pattern, so I decided to try my hand at bringing it into Go. it isn't officially published, yet, but you can see what I've come up with at https://github.com/Roundaround/cva-go. It pairs nicely with the tailwind-merge port by @Oudwins and a very simple implementation might look something like this:

package components

import (
	twmerge "github.com/Oudwins/tailwind-merge-go"
	"github.com/Roundaround/cva-go"
)

type Size int

const (
	Small Size = iota
	Medium
	Large
)

const DefaultSize = Medium

type ButtonProps struct {
	classes []string // Classes applied after the built-in ones
	size    Size     // The variant we want to bind with cva-go
}

var button = cva.NewCva(
	"inline-flex items-center justify-center gap-2 whitespace-nowrap rounded-md text-sm font-medium transition-colors",
	cva.WithVariant(
		func(p ButtonProps) Size { return p.size },
		map[Size]string{
			Small:  "h-9 px-3",
			Medium: "h-10 px-4 py-2",
			Large:  "h-11 px-8",
		},
	),
	cva.WithClassJoiner[ButtonProps](func(parts []string) string {
		return twmerge.Merge(parts...)
	}),
	cva.WithClasses(func(p ButtonProps) []string {
		return p.classes
	}),
)

templ Button(p ButtonProps) {
	<button class={ button.ClassName(p) }>
		{ children... }
	</button>
}

I spent a lot of time writing and rewriting (I think I had somewhere in the order of 7 or 8 different implementations before I landed on this one) and I think there's still room for improvement before I even consider publishing it as an official package. What do you all think?

[Roundaround]

Did you think about having your props implement an interface instead of having to define cva.Classes()?

I did actually, and I tried really hard to get it to work the way I wanted, but that tightly couples the additional classes to the props themselves rather than the cva function. It's a relatively common pattern to use cva multiple times for a single component (i.e. once for the root element, once for the img, etc.). For simple cases you can use Tailwind's child selectors for this (like in the example below selecting the child svg element), but it gets out of hand quickly if a lot of your component tree needs adjusted based on variants. If the "override" classes comes directly from the props, there's no way to only conditionally apply it.

IMO it's better to have an optional part of the API (as long as it's simple, like this is) than to force everyone that wants to work around it to implement their own helper functions or wrappers

Or just not have CVA handle the additional classes at all and leave that up to whatever class processor you use (be it a simple join or a merger)

Honestly I would be perfectly happy with that, if it weren't for the fact that it's a feature of cva and I know people commonly use it. Really though, it's one of those "use it if you want it, forget it if not" kinds of things. These are mostly equivalent:

props := Props{
	classes: []string{"custom"},
}

// Using Classes func
button1 := cva.New(
	cva.Base[Props]("button"),
	cva.Classes(func(p Props) []string {return p.classes}),
)
fmt.Println(button1.Classes(props))
// Output: button custom

// Not using Classes func
button2 := cva.New(
	cva.Base[Props]("button"),
)
fmt.Println(button2.Classes(props) + " " + strings.Join(p.classes, " "))
// Output: button custom

The only difference here being that internally, cva-go is doing a strings.TrimSpace and a regexp replace on multi-spaces to ensure the output is clean, so a simple join isn't quite the same. If you happen to be using twmerge.Merge anyway, then this isn't a problem, but it means those who aren't in Tailwind world get shafted (or I'd have to expose the function that joins and cleans the whitespace as another helper) 🤷‍♂️

Maybe some examples on the compound variants, haven't given it a try myself but would be nice to see it used practically.

I do have an example [https://github.com/Roundaround/cva-go#compound-variants](in the README). Not the most in-depth of examples, but it at least gives you a good idea for the use case and syntax:

type Props struct {
	Size  string
	Style string
}

button := cva.New(
	// ...
	cva.CompoundVariant(
		func(p Props) (string, string) { return p.Size, p.Style },
		cva.NewCompound("small", "icon", "[&_svg]:size-4"),
		cva.NewCompound("medium", "icon", "[&_svg]:size-5"),
		cva.NewCompound("large", "icon", "[&_svg]:size-6"),
	),
)

Honestly though I still don't love the compound variant support since it's locked at two values, but I can't think of a way to make it any better without some kind of list of separate CompoundVariantN functions, all coded in for their associated static variant prop counts:

func CompoundVariant[P any, V1 comparable, V2 comparable](
	getter func(P) (V1, V2),
	compounds ...Compound[V1, V2],
) Option[P] {
	// ...
}

func CompoundVariant3[P any, V1 comparable, V2 comparable, V3 comparable](
	getter func(P) (V1, V2, V3),
	compounds ...Compound3[V1, V2, V3],
) Option[P] {
	// ...
}

func CompoundVariant4[P any, V1 comparable, V2 comparable, V3 comparable, V4 comparable](
	getter func(P) (V1, V2, V3, V4),
	compounds ...Compound4[V1, V2, V3, V4],
) Option[P] {
	// ...
}

// ... up to ??

But for a v1 it's probably good enough, because anyone with a need for compounds with higher variant counts can compose the logic themselves through the getter functions:

type Props struct {
	A string
	B  string
	C  string
}

button := cva.New(
	// via string joining and variant map
	cva.Variant(
		func(p Props) string { return strings.Join([]string{p.A, p.B, p.C}, ":") },
		map[string]string{
			"a1:b1:c1": "foo",
			"a1:b2:c1": "bar",
			// ...
		},
	),

	// via several predicates
	cva.PredicateVariant(
		func(p Props) bool { return p.A == "a1" && p.B == "b1" && p.C == "c1" },
		"foo",
	),
	cva.PredicateVariant(
		func(p Props) bool { return p.A == "a1" && p.B == "b2" && p.C == "c1" },
		"bar",
	),
	// ...
)

Not ideal by any measure, but it "works"

[AlexanderArvidsson]

Hehe, I guess I haven't used CVA in any other way than the most simple example, never needed to do any fancy stuff.
But that's fine, as long as it's not needed. I believe a simple minimal API is the best, with the option to additionally add more advanced features, just like you've done.

Missed the compound variants in the README for some reason, maybe I was tired! 😅
Interesting solution for the predicate variants actually, hadn't thought about that!
I do have a use-case for multi-variants actually from CVA:

    {
      variant: 'primary',
      outline: ['ghost', 'dashed'],
      class: "bg-transparent border-token-button-primary hover:border-token-button-primary-hover",
    },

But I am totally fine with having these as separate variants, this is just syntactic sugar. Actually, you could argue that having both outline=ghost and outline=dashed is unnecessary, as you could simply do <Button class="border-dashed" outline="ghost"> 🤷

All in all I think this is the best version of a Go CVA so far, good job :)

[Roundaround]

this is just syntactic sugar

This comment got stuck in my head last night. At the end of the day, this is all just syntactic sugar for conditionally appending strings together. In fact, the base CVA lib itself is just syntactic sugar on top of clsx, which got me thinking - am I going about this the wrong way? What if instead of building out a proper "port" of CVA, we instead try to reimagine it? And probably most importantly...

What do we actually want out of something like CVA?

Ultimately I think we want a clean and easy way to say "under condition X, include Y class(es)". I think a lot of the time the PredicateVariant can do this, like with your example:

cva.PredicateVariant(
	func(p Props) bool { return p.variant == "primary" && (p.outline == "ghost" || p.outline == "dashed") },
	"bg-transparent border-token-button-primary hover:border-token-button-primary-hover",
)

But this and the other variants are just syntactic sugar on what should probably be the base functionality of mapping some props input to a string. Given a generic "Fn" (Function) option, we could implement the PredicateVariant above like so:

cva.Fn(func(p Props) string {
	if p.variant == "primary" && (p.outline == "ghost" || p.outline == "dashed") {
		return "bg-transparent border-token-button-primary hover:border-token-button-primary-hover"
	}
	return ""
})

Or to implement the base Variant that uses a map, I think back to the switch-based pattern @Oudwins mentioned earlier in the discussion:

cva.Fn(func(p Props) string {
	switch p.Size {
	case "small":
		return "h-9 px-3"
	case "medium":
		return "h-10 px-4 py-2"
	case "large":
		return "h-11 px-8 py-3"
	default:
		return ""
	}
})

Which also means if you want to return the same classes for multiple variants:

cva.Fn(func(p Props) string {
	switch p.Size {
	case "small":
		return "h-9 px-3"
	case "medium", "large":
		return "h-11 px-8 py-3"
	default:
		return ""
	}
})

And of course the Base function can easily be recreated:

cva.Fn((p Props) string { return "inline-flex items-center justify-center" })

For a lot of people, a Fn option inside the existing Cva joining/composing API is probably already enough syntactic sugar to do everything they need to do, but I really think there's an opportunity to enable the other common patterns with more targeted helpers. As I said above, I think most of them can be boiled down to "if X, include Y", so some kind of simple predicate option should exist and can be the functional basis for several more specific ones:

• A specific property equals a specific value: p.v == x
• A specific property exists in a list: slices.Contains([]T{x, y, z}, p.v)
• The complement (inverse) of any condition: !condition(p)
• The union of any conditions: conditionA(p) && conditionB(p)
• The intersection of any conditions: conditionA(p) || conditionB(p)

But how do we express each of these cases without over-bloating our API or making the syntax too verbose? As much as I've been trying to avoid it, the answer might actually just be to eliminate the getters, likely via reflection (struct tag or field name lookups) or interfaces. That might be the best chance we have to express our conditionals as simple pattern matching rather than full boolean expressions.

Still not entirely sure how that will work within the bounds of Go's type system though. Gotta think through it a bit more...

EDIT: I realized after I wrote all this that the Fn option I imagined actually already exists as Classes, albeit returning a string rather than a []string 😂

[Roundaround]

SO I ended up starting from (almost) scratch...and had the idea of declaring the variants first, then building the matchers off them with boolean operator style functions.

type Props struct {
	Size    string
	Classes []string // override classes from i.e. a parent component
}

var size = cva.NewVariant(func(p Props) string { return p.Size })

var button = cva.New(
	cva.Base[Props]("inline-flex items-center justify-center"),
	size.Map(map[string]string{
		"small":  "h-9 px-3",
		"medium": "h-10 px-4 py-2",
		"large":  "h-11 px-8 py-3",
	}),
	cva.Classes(func(p Props) []string { return p.Classes }),
)

func Example() {
	fmt.Println(button.Classes(Props{"medium", []string{"bg-red-500"}}))
}

Or a more complete example...

// While not required, consider enum-style custom types to prevent too many "magic values"
type Size int
type Theme int
type Element int

const (
	SizeSmall Size = iota
	SizeLarge
)

const (
	ThemeDanger Theme = iota
	ThemePrimary
)

const (
	ElementButton Element = iota
	ElementLink
	ElementIcon
)

type Props struct {
	Size    Size
	Theme   Theme
	Element Element
}

// Variants are basically special mappers from whatever input type to the value of the variant.
// In this case, the input type is a struct called Props with a field for each variant, but it
// could be anything from which the variant values can be derived.
var size = cva.NewVariant(func(p Props) Size { return p.Size })
var theme = cva.NewVariant(func(p Props) Theme { return p.Theme })
var elem = cva.NewVariant(func(p Props) Element { return p.Element })

// You can also specify accepted values and defaults for your variants if your data is not always
// sanitized ahead of time:
//
// size = cva.NewVariant(func(p Props) Size { return p.Size }).
//   WithValues(SizeSmall, SizeLarge).
//   WithDefault(SizeSmall)

var button = cva.New(
	// Apply classes no matter what
	cva.Base[Props]("px-4 py-1"),

	// Apply classes based on 1:1 mappings to variant values
	size.Map(map[Size]string{
		SizeSmall: "px-2",
		SizeLarge: "px-6 py-2",
	}),
	theme.Map(map[Theme]string{
		ThemeDanger:  "bg-red-500 text-white",
		ThemePrimary: "bg-blue-500 text-white",
	}),

	// Construct matchers using Variant.* (Is, In, IsNot, NotIn, or Test)
	elem.Is(ElementIcon).Then("rounded-full"),
	elem.IsNot(ElementIcon).Then("rounded-md"),
	// elem.In(ElementButton, ElementLink).Then("rounded-md"),

	// Compose complex matchers using Matcher.* (Or, And, Not)
	size.Is(SizeLarge).And(theme.Is(ThemeDanger)).Then("font-bold"),
	elem.Is(ElementIcon).And(size.IsNot(SizeSmall)).Then("[&_svg]:size-5"),

	// Use Any, All, and When if method chaining is not your cup of tea
	cva.When(elem.Is(ElementLink), "text-blue-500 hover:text-blue-600 bg-transparent"),
)

func Example() {
	fmt.Println(button.Classes(Props{SizeLarge, ThemeDanger, ElementLink}))

	// Of course, you might also want to use tailwind-merge-go:
	// fmt.Println(twmerge.Merge(button.Classes(Props{SizeLarge, ThemeDanger, ElementLink})))
}

Still uses the same New(opts ...Option) pattern as before (and heck, we can keep everything I had in case there's one-off props that users don't want to define a variant for ahead of time), but now with a new API for constructing each variant matcher/case that is WAY less verbose and WAY more flexible 👀

[Roundaround]

I took some time away while I worked on some other projects but came back last night to clean up the tests and examples dir and add some basic doc comments to the new bits. I figured it's in a good enough place that I can consider the API stable at this point. I know the examples, README, and probably the tests all need a bit more work to provide more clarity but the public-facing API is pretty settled. If you want to try using it in your project for a more hands-on experience you can try it out with go get github.com/Roundaround/cva-go now 😎

[axadrn]

Just use templUI - The UI Kit for templ 🔥

[Roundaround]

First of all let me say templUI is fantastic. Great project for bootstrapping or even just as reference material!

In general I appreciate component libraries and know they have their place, especially for bootstrapping a new project or prototyping...but in my experience more often than not (especially in larger projects or corporate environments) they end up a hinderance because they shoehorn projects into a specific style, functionality, or layout.

The spirit of this thread and what I'm hoping to build/find is a pattern for more easily building components that fit the exact specifications of the project at hand. It's easy to just say "use this component library!" (especially when you're financially incentivized to advertise...👀), but then the moment we need something custom it feels bad 😔

[axadrn]

Thanks for your honest feedback. You're right, of course I also have the incentive to earn money through the pro version at some point. But the fact is that templUI is primarily a completely independent open source UI library, and this concept won't change.

Since yesterday, I've had the templUI CLI in beta, which continues the shadcn/ui approach of "Build Your Component Library," meaning components are copied directly into your codebase. This gives you full control over custom styling.

If you'd like to check it out, here's the link to the GH discussion:

templui/templui#150

[axadrn]

Just a quick follow-up to my previous comment about the templUI CLI beta:
It's officially live now in templUI v0.70.0! 🎉