What do you think of the API?

[markuswustenberg]

I'm experimenting with the gomponents API, to make it as easy as possible to build view components in Go. What do you like? What don't you like? Let me know below. All feedback is appreciated. 😊

[jfyne]

Hi @markuswustenberg, liking what you have done with this. I'm just playing around with gomponents now, what would you say is the best way to do conditional rendering?

Have I missed something in the API?

[jfyne]

My bad, missed If

[markuswustenberg]

Yeah, I just recently added If, and I don't think I have it in the documentation yet. Thanks for giving the module a spin, I hope you find it useful. 😊

[markuswustenberg]

@jfyne I see you're playing with view libraries as well. Interesting. Have you seen what they're up to at Basecamp? https://hotwire.dev looks interesting. I believe there are people who've tried it in Go as well, but I haven't tried it out myself yet.

[jfyne]

I have seen that. From what I gather you have to write basically API endpoints that return html fragments... Which sounds annoying to me.

My approach in jfyne/live has been to copy phoenix liveviews and just send patches through.

I'm just getting together an implementation of components to sit on top of that which is where my interest in your library came from.

If you look at jfyne/part in the examples folder, I've used gomponents to render a page. I liked your API, was a little confused that attributes were nodes at first but it makes sense to simplify the API.

[markuswustenberg]

I had a look, it looks interesting. I think I'll try it out later. I have a use case where I cannot switch the page (because of audio running in the page) and users should be able to comment. Currently I'm actually loading a page fragment via a custom API and a bit of javascript, but it feels a bit hacky.

Yeah, you're not the first to be confused by the element/attributes mix. I'm still thinking about if there is a better way. Suggestions are welcome. 😊

[ksthiele]

Very, nice, but one question are (or can) the components (be) loaded concurrently or is it planned to do so?

[markuswustenberg]

All components are just functions without any global state, so there are no concurrency concerns from the library's end. 😊

[dedalusj]

I know this is an old discussion and the API is likely not open for changes any more but I was wondering if you ever considered or would consider an API like the following:

type Node func(w io.Writer) error

type Attribute Node

type Element Node

// example of an attribute
func Class(classes ...string) Attribute {...}

// example of an element
func Div(attr ...Attribute) func(...Element) Element {...}

which would make the components look like the following:

func NewTaskForm() Element {
	return Form(HxPost("/todos"), Class("new-task"))(
		Input(Type("text"), Class("task-text"), Name("text"), Required(), Placeholder("Type new task")),
		Button(Class("new-task"))(Text("Add task")),
	)
}

The main difference being that Elements are functions that take a list of attributes and return a function that takes a list of other elements. It would create more separation between attribute nodes and element nodes where Elements have other Elements as children which looks more like natural HTML or JSX (at least to me).

[markuswustenberg]

That's also quite elegant. 😊

I don't know whether it would make much difference in practice, though. As you already mentioned, I'm not going to change the API at this point, but your idea would probably also work.

[BoilingSoup]

I love the API!! Can't think of a single thing I don't like about it. Thank you for the awesome library

[markuswustenberg]

I’m glad you like it. :D

[BoilingSoup]

I have a question somewhat API related,

Does Gomponents support returning fragments? Similar to React.Fragment for when the component doesn't have a top level element.

React JSX example:

<>
    <h1>I'm the first element</h1>
    <h2>I'm the second element</h2>
</>

Edit: Oh I see it's g.Group ! perfect

[markuswustenberg]

Yeah, g.Group does something similar, but it can't currently render on its own. I've got an issue for that: #162.

[BoilingSoup]

That's good to know! I see that g.Group panics if I try to render it directly.

It's not a super common situation but I do see myself running into it when using gomponents with htmx.

[markuswustenberg]

Yeah, you're not the first to raise this. My thinking with Group was to make it hard to use wrong, because rendering attributes at the root layer (without a root node) is nonsensical. But I think I want to relax that restriction a bit. Maybe it'll just panic for attribute nodes at the root, or not render them.