6 ms·

Thank you for the mention! :) Relevant libraries, for those who want to dive directly into it: - https://github.com/maragudk/gomponents https://github.com/mar

Thank you for the mention! :) Relevant libraries, for those who want to dive directly into it: - https://github.com/maragudk/gomponents https://github.com/maragudk/gomponents - https://github.com/maragudk/gomponents-htmx https://github.com/maragudk/gomponents-htmx

arccy 3y ago
i just wish gomponents/html would define an alias for gomponents.Text so i don't have the impedance mismatch of switching the package qualifier but otherwise, I'm quite liking it so far
- markusw 3y ago
  Hmm. I see what you mean, but <text> isn't a valid HTML element, so that wouldn't work for that alone. But try dot imports for the html package and you don't have to have a package qualifier for most of your view code at all! :D
egeozcan 3y ago
Oh, thank you for open sourcing it! I'm having a lot of fun, and it's nearly as agile as react, only hit by the lack of expressiveness in the go language in some cases.
- markusw 3y ago
  You're welcome! :) I'm always open for feedback, so if you think there's room for improvement, feel free to open an issue for discussion on the repo. (That said, I'm fairly conservative about the API, trying to keep it simple for everyone to use.)
tauchunfall 3y ago
I tried it yesterday until far past midnight. gomponents is amazing! I find the abstractions just right. it now looks possible that I can port my minimalistic bun/deno setup with htmx to go. I found "gow" watcher that allows auto-restart of the development webserver when go code was changed. And I'm using "hx-refresh" header paramter and "hx-trigger='every 250ms'" to have a simple polling browser refresh. it also integrates well with tailwind css. you can use tailwind vscode extension and define a custom "classRegex" for gomponents "Class(...)" function. I needed to write a custom `Classes()` function that allows me to have conditional classes like `clsx()`. it's a bit hacky, but I like the simplicity. func Classes(nodes ...g.Node) g.Node { var classes []string for _, node := range nodes { if node != nil { var builder strings.Builder _ = node.Render(&builder) c := builder.String() c = strings.TrimLeft(c, " class=\"") c = strings.TrimRight(c, "\"") classes = append(classes, c) } } return Class(strings.Join(classes, " ")) } the runtime panics for functions that use vararg for optional arguments and have an invalid number of arguments is probably an okayish trade-off. mixing attributes and children elements in the builder functions, I don't know if it's good or bad, but I like the simplicity; JSX and hyperscript-like functions separate tag, attributes, and children into three different parameters. edit: reformat and typos.
- markusw 3y ago
  I'm really happy you like it. :) And thank you for your comment, I really appreciate newcomer viewpoints especially. Have a look at the `Classes` helper component already available: https://github.com/maragudk/gomponents/blob/main/components/components.go#L42 https://github.com/maragudk/gomponents/blob/main/components/... Yeah, I'm not a total fan of the runtime panics, but it was a tradeoff where I chose in favour of API simplicity and readability. In practice, it works out well, because you catch any typos at development time. I've had elements and attributes in separate packages before, but then you can't dot-import both packages and not have name clashes, and have to either prefix elements or attributes with the package name, which makes the code much less readable. Again, a tradeoff. :)

arccy 3y ago

i just wish gomponents/html would define an alias for gomponents.Text so i don't have the impedance mismatch of switching the package qualifier but otherwise, I'm quite liking it so far

markusw 3y ago
Hmm. I see what you mean, but <text> isn't a valid HTML element, so that wouldn't work for that alone. But try dot imports for the html package and you don't have to have a package qualifier for most of your view code at all! :D

egeozcan 3y ago

Oh, thank you for open sourcing it! I'm having a lot of fun, and it's nearly as agile as react, only hit by the lack of expressiveness in the go language in some cases.

markusw 3y ago
You're welcome! :) I'm always open for feedback, so if you think there's room for improvement, feel free to open an issue for discussion on the repo. (That said, I'm fairly conservative about the API, trying to keep it simple for everyone to use.)

tauchunfall 3y ago

I tried it yesterday until far past midnight. gomponents is amazing! I find the abstractions just right. it now looks possible that I can port my minimalistic bun/deno setup with htmx to go. I found "gow" watcher that allows auto-restart of the development webserver when go code was changed. And I'm using "hx-refresh" header paramter and "hx-trigger='every 250ms'" to have a simple polling browser refresh. it also integrates well with tailwind css. you can use tailwind vscode extension and define a custom "classRegex" for gomponents "Class(...)" function. I needed to write a custom `Classes()` function that allows me to have conditional classes like `clsx()`. it's a bit hacky, but I like the simplicity. func Classes(nodes ...g.Node) g.Node { var classes []string for _, node := range nodes { if node != nil { var builder strings.Builder _ = node.Render(&builder) c := builder.String() c = strings.TrimLeft(c, " class=\"") c = strings.TrimRight(c, "\"") classes = append(classes, c) } } return Class(strings.Join(classes, " ")) } the runtime panics for functions that use vararg for optional arguments and have an invalid number of arguments is probably an okayish trade-off. mixing attributes and children elements in the builder functions, I don't know if it's good or bad, but I like the simplicity; JSX and hyperscript-like functions separate tag, attributes, and children into three different parameters. edit: reformat and typos.

markusw 3y ago
I'm really happy you like it. :) And thank you for your comment, I really appreciate newcomer viewpoints especially. Have a look at the `Classes` helper component already available: https://github.com/maragudk/gomponents/blob/main/components/components.go#L42 https://github.com/maragudk/gomponents/blob/main/components/... Yeah, I'm not a total fan of the runtime panics, but it was a tradeoff where I chose in favour of API simplicity and readability. In practice, it works out well, because you catch any typos at development time. I've had elements and attributes in separate packages before, but then you can't dot-import both packages and not have name clashes, and have to either prefix elements or attributes with the package name, which makes the code much less readable. Again, a tradeoff. :)