Thoughts on a more ergonomic styling API (and additive classes?)

[deitrix]

Hey,

I just came across this library and whilst I was having a play around with it, I couldn't help but think the styling API felt a bit... lacking. Having only Style which accepts a string means that style building is entirely up to the user of the library.

I propose a more declarative API, introducing a new style package within the repo. Usage would look a little like:

import s "github.com/maragudk/gomponents/style"

func Navbar(currentPath string) g.Node {
	return Nav(
		s.Styles(
			s.Display(s.DisplayBlock),
			s.Padding(s.Rem(2)),
			s.BackgroundColor(s.RGBA(255, 255, 255, 70)),
			s.Color(s.RGBA(0, 0, 0, 100)),
			s.FontSize(s.Px(20)),
			s.TextAlign(s.AlignCenter),
			s.Custom("border-bottom", "1px solid black"),
		),
		NavbarLink("/", "Home", currentPath),
		NavbarLink("/about", "About", currentPath),
	)
}

My only concern is that it's a lot of nodes to define (there are a lot of different styles!). But, a lot of helper/utility functions could be introduced to make the style definition process more straightforward, and less error-prone for the user.

Let me know your thoughts! 😃

[markuswustenberg]

Hi @deitrix. Thank you for wanting to improve the library! 😊

This reminds me of a discussion we had of defining all HTML attribute values as constants. (I can't remember where it was, somewhere here on Github.) Ultimately, I decided it wasn't really worth the effort required, and would clutter the API surface.

In this case, you would basically be "porting" CSS to Go, and my gut feeling tells me that's a lot more work than "porting" HTML.

What would be the main advantage of this, you think, apart from preventing typos in strings? I have a hard time wrapping my head around what the advantages would be. I guess it's because I don't really have experience building components this way, I use TailwindCSS for everything.

[deitrix]

I do have one suggestion. When using the Class attribute multiple times within a component, it would be great if they could somehow be combined into one attribute. Take the following for instance

func Btn(children ...Node) Node {
	return A(Class("no-underline text-white text-sm py-0.5 px-2"), Group(children))
}

func BtnPrimary(children ...Node) Node {
	return Btn(Class("bg-blue-600 hover:bg-blue-500"), Group(children))
}

btn := BtnPrimary(Href("/"), Text("Home"))
btn.Render(os.Stdout)

yields

<a class="no-underline text-white text-sm py-0.5 px-2" class="bg-blue-600 hover:bg-blue-500" href="/">Home</a>

[markuswustenberg]

I get what you're saying, and you're not the first to say it. But it's definitely a non-goal of this library to validate the HTML that it spits out, which includes duplicate attributes.

The reason is that validating HTML is such a complex subject, I don't even want to try. 😅

Think of it more like writing HTML directly, but in Go with a slightly different syntax.

In your particular case, you might be looking for the Classes helper component: https://pkg.go.dev/github.com/maragudk/gomponents@v0.20.5/components#Classes . With it, you can conditionally apply CSS classes. So your Btn would look something like this:

func Btn(primary bool, children ...Node) Node {
	return A(Classes{"no-underline text-white text-sm py-0.5 px-2": true, "bg-blue-600 hover:bg-blue-500": primary}, Group(children))
}

[deitrix]

The reason is that validating HTML is such a complex subject, I don't even want to try. 😅

I don't blame you! 😅 Regardless, I'll draw something up and see what you think of it. I don't think any HTML parsing would be required to achieve what I'm thinking of. It would just be a case of detecting if multiple attr nodes of the same type are passed as children, then the attribute itself would be responsible for combining them (maybe a different Attr constructor that accepts a concat func?). For the case of Class, I don't see why space-separating and joining the two lists wouldn't work?

In your particular case, you might be looking for the Classes helper component

Thank you! That's actually very useful to know 🙂

[deitrix]

Check out https://github.com/maragudk/gomponents/compare/main...deitrix:gomponents:attribute-concat?expand=1

This is obviously a breaking change to the library, and doesn't yet fit all use cases (namely, custom attribute implementations). Upon further reflection, it might make more sense for this to be a tailwind-specific utility. But, it would still require a modification of the library to allow for this sort of concatenation functionality. Maybe this is out of scope for gomponents, but possibly an extension library like htmx/lucide? 🙂

And completely by accident, this solves my original issue with Style 😀

[markuswustenberg]

@deitrix I'm happy you found a solution, even by accident! :D

I don't think this is something I want to pursue in the core library. But maybe it would make sense to make an "intelligent" attribute grouper component that does something like this.

I've just made a new repo for contributed components at https://github.com/maragudk/gomponents-gallery, feel free to add something like this there if you'd like to share this (or something else entirely at another point).

No matter what, thank you again for your input. It's much appreciated. 😊