Added hx-confirm and hx-delete.

[remast]

No description provided.

[remast]

This is one little piece that was missing for me when I migrated my custom code from https://github.com/Baralga/baralga-app to gomponents-htmx.

[markuswustenberg]

Thank you! 😊

[markuswustenberg]

(I plan to add the remaining attributes tomorrow, so will release then.)

[markuswustenberg]

@remast @lobre v0.3.0 now released! Give it a spin and let me know what you think. 😊 Feel free to connect on Mastodon: https://hachyderm.io/@markus

[markuswustenberg]

Does anyone know how I get Github to show contributors on the front page of the project?

[lobre]

Awesome, thanks for having implemented all of that! That’s really practical!

I don’t know how to show contributors, or at least if there is a way to add them on the front page automatically...

I am not a super fan of having to import all those different libraries, I would prefer a single import for gomponents, and another for htmx, but I can understand that you think it is better "organized", especially in the documentation (even if I would not bother myself :-)).

It scares me a little if more and more libraries are supported, it could generate dozens of lines of import if I want to use them all.

g "github.com/maragudk/gomponents"
c "github.com/maragudk/gomponents/components"
. "github.com/maragudk/gomponents/html"
ghttp "github.com/maragudk/gomponents/http"
hx "github.com/maragudk/gomponents-htmx"
hxhttp "github.com/maragudk/gomponents-htmx/http"

Apart from this, it is really cool as it gives a lot of joy to be able to do frontend templates that easily in go!

[markuswustenberg]

I am not a super fan of having to import all those different libraries, I would prefer a single import for gomponents, and another for htmx, but I can understand that you think it is better "organized", especially in the documentation (even if I would not bother myself :-)).

It scares me a little if more and more libraries are supported, it could generate dozens of lines of import if I want to use them all.

g "github.com/maragudk/gomponents"
c "github.com/maragudk/gomponents/components"
. "github.com/maragudk/gomponents/html"
ghttp "github.com/maragudk/gomponents/http"
hx "github.com/maragudk/gomponents-htmx"
hxhttp "github.com/maragudk/gomponents-htmx/http"

Apart from this, it is really cool as it gives a lot of joy to be able to do frontend templates that easily in go!

@lobre yeah, it looks a bit chaotic when it's all jumbled together. Normally, I would have the html-related imports in a separate package html, and the http and htmx stuff in an http package (or similar), then it doesn't look quite so bad. But I get what you mean.

For gomponents, it made sense to me to have all low-level HTML elements and attributes in a separate package, so they can be dot-imported. The higher-level components (such as Classes) I put in a components package because I didn't want to mix them with the native HTML stuff. And It felt wrong to have those together with the core utilities in the gomponents package. So that's why they're separated. (There's also an svg package.)

It's the same with HTMX: the attributes are in the base package (so they can be aliased easily with hx), the http helpers are separate because they would be used in a separate place and probably package.

I'll think about if this can be improved. Thank you for your feedback!

[lobre]

Have you thought of trying to namespace different things in the same package? This Reddit thread explains a little bit about how this is used in the encoding/binary package.

https://www.reddit.com/r/golang/comments/hocwje/just_found_out_that_we_can_namespace_functions_in/

I am not saying that it would be a superior design, but maybe worth being considered. For instance, there could be only one package github.com/maragudk/gomponents and then we could have something like:

// HTTP stuff could be a the root level
type Handler
// Adapt could be renamed to AdaptHandler
func AdaptHandler(h Handler) http.HandlerFunc

// HTML stuff could be namespaced using El and Attr, and this would prevent clashes for the same names.
// However, this would prevent using them without prefixes and you cannot assign them to "." anymore.
var El el
type el struct{}
func (el) Article(children ...g.Node) g.Node {...}
func (el) Aside(children ...g.Node) g.Node {...}

var Attr attr
type attr struct{}
func (attr) Disabled() g.Node {...}
func (attr) Required() g.Node {...}

// For the rest, I would not mind having them at the root either

It is just a quick draft of what could me made, but there are other ways to organize that.

And the code could be split into different files in the root package, to keep the "structure" and have the code still easily understandable.

I am sure you will not like it, as it surely feels less tidy from a package designer perspective, but for a user, it could be handy to only have to import one package to use gomponents.

I think it is what people like with html/template. They can just import it and use it, as it feels to be "one domain" = generating HTML. The documentation ends up being in the same place, in this unique package.

Would love to hear your thought about this, even if I know it could be a little opinionated ^^

[markuswustenberg]

@lobre thank you again for taking the time to provide feedback.

You guessed correctly. 😋 But not for the reasons you outlined. My thinking is:

1. There's already a well-known namespacing mechanism in Go, and it's the package. I don't think introducing a different one is superior to that, basically for the gain of skipping a line of import.
2. As you mentioned, dot imports (or whatever name you want to give the import) would not be possible this way, and I think that's a core developer experience win for these libraries.
3. It would break existing library users. Not so bad for this HTMX one, quite bad for gomponents.

I hope that's a satisfactory answer. 😊

[lobre]

Makes sense, thanks for taking the time to answer