Merge multiple occurrences of the `class` attribute

[maragudk]

Merge multiple occurrences of the `class` attribute

[markuswustenberg]

Hi @tbe, thank you for your contribution!

I actually like the way that the library is "dumb" in the way that, if you provide it with invalid HTML, it will happily render that, just like if you wrote raw HTML. However, I see your point.

I think in your case it would make sense to bake the is-primary functionality into the button itself:

type BulmaButtonProps struct {
    IsPrimary bool
}

func BulmaButton(p BulmaButtonProps, children ...g.Node) g.Node {
    return Button(c.Classes{"button": true, "is-primary": p.IsPrimary}, g.Group(children))
}

So basically the button "owns" the various ways in which it can be rendered. Would that solution solve your issue?

[tbe]

Hey @markuswustenberg , that is the exact usecase why i open this issue.
While "dump" rendering is fine if you use the gomponents directly, in this case it is not obvious to a user what happens. If the user provides another set of classes, the "is-primary" will be shadowed, or it will shadow the user supplied classes, however the browser decides.

As the type of the attributes is not exported, we can't apply any check in the factory function for the button.

[markuswustenberg]

Yes, that's true, there can be attribute clashes in general. I think there's no way around that in gomponents because of the way I've designed it. Solutions that I can currently think of:

1. Document that the user of the BulmaButton shouldn't use separate class attributes.
2. Don't accept arbitrary Node children but only custom types.
3. Put children nodes on a child node of the button and not the button directly, thus creating a sort of wrapper node inside the button.
4. Render all children nodes and check for disallowed attributes.

Would any of those work in your use case?

[tbe]

After thinking about it, i see your concerns. My needs differ from the design philosophy behind gomponents. So i decided to write an alternative module, that sacrifices a little bit of usability for more advanced features. Should hit github today or tomorrow.

The main reason is, that implementing the proposed logic on top of gomponents is most likely the same work and adds nothing but an extra layer of abstraction.

Thank you for the great project @markuswustenberg , i got a lot of inspiration from it.

[markuswustenberg]

I'm happy you found a solution, @tbe. 😊