Proposal: Gomponents Community Library - shadcn/ui style

[camstuart]

Context

The goal of components is to share, between your own projects and with other community members. However, a big challenge is doing so in a generic enough way that components satisfy enough needs to be useful, without being too opinionated. This can be discouraging to would be component authors, as they they need to address their own requirements first, and may not have enough time to think about and implement the needs of others.

Proposal

Follow the approach of shadcn/ui by actually generating source code into ones project, rather than importing a library.

Once the Gomponent is generated, the project author can use it as is, or modify it as required.
Almost like vendoring Go packages like we did back in the day.

Approach

1. Define an acceptable repository structure for one or more Gomponents, along with their tests (if any). This should include some metadata in a known format. Or alternatively have a central Awesome mono repo that contributors send PR's to.
2. Produce a simple CLI tool that accepts a Gomponent repo url, and a sub command, eg list (display metadata) and pull <gomponent-name>

The CLI simply grabs the Gomponent sources and related tests, and places them into your project. Perhaps there are some overrides on path and package. But in the first instance, follow @markuswustenberg convention of path html package html

From here, the project owner uses the Gomponent as is, or makes whatever modification they feel are needed (usually style adjustments)

This allows Gomponent authors to focus on functionality and ignore style concerns. Hopefully motivating them to share.

IE: I would rather tweak an existing Gomponent that almost fits my needs, than build from scratch. And a streamlined copy paste mechanism would be useful.

[glsubri]

I've also been thinking about something like this in the last weeks.

While I think the approach of shadcn/ui works really well in the javascript world, I wonder how much it would stick in the go world. People in javascript-land are very used to importing tons of libraries, having a lot of config files and needing tools like transpilers, bundlers, etc... Contrasting that with Go where there isn't much that can't be done through the go command.

For example, one of the reasons for which I enjoy using gomponents instead of templ, is the fact that it's just Go. No new types of file. No extra building step. No weird syntax. Just Go. It's simple.

I love the idea of having shared gomponents, but I think that if it gets too complicated, most people will just not use it.

Additionally, I feel like, while fragmented in thousands of libraries, the javascript world does revolve around React, tailwindcss and some other core projects. Which means that most people use the same tech stack. Having this amount of people makes these component libraries much more worth it in terms of time invested.

As a "food for thought", I've really enjoyed the way some component libraries like https://www.hyperui.dev/ or https://www.penguinui.com/ approach the problem. They simply show you the code of the component in HTML (and with some AplineJS if you want). The big downside to this for me right now, is that I need to translate HTML to Gomponents.

If this could be automated (at least partly) for React (like https://htg.piotrkowalski.me/ for HTML), maybe we would be able to benefit from reusing shadcn/ui or other existing component libraries instead of making a new one.

In any case, I'd much rather have something than nothing.
I'm happy to help if this moves forward

[camstuart]

I agree, the JavaScript world is chaotic. Perhaps then, the simplest approach is have a single repo with the gomponents and a github action that generates a website on github pages with the go code ready to be copied. This should not be hard to set up I would think

[markuswustenberg]

I think the idea is super interesting. I agree it depends a lot on being simple to use, "Go-style".

I've already started a gallery repo here: https://github.com/maragudk/gomponents-gallery . I'm not sure whether a central repo with PRs or supporting separate repos would make sense.

I've started an official html2gomponents tool here, maybe it would make sense to make a more general tool for gomponents: #232

I'll think about this some more. 😊