Have you considered html like components?

[SebastianStehle]

I am new to golang and templ, so I am sorry if I am ask something stupid.

In many other platforms components look like normal html components, e.g. react, razor (c#), web components and so on. I was thinking how to use a css component library or tailwind with templ and ideally I would create custom components to only have a single definition of a button.

But the current syntax for that is very noisy. So my proposal would be to introduce xhtml like components. My example is from this issue: #229

package "app"

type AppButtonProps struct {
  templ.TemplHtmlButtonProps
  Variant   string   `validate:"required"`
  Size      string     `validate:"oneof=lg md sm"`
}

component Button(props AppButtonProps) {
  <button {...props }>
    { children... }
  </button>
}

templ Body() {
    <app:button variant="color" size="sm" />
}

Summary:

• A component is just a normal function, with the component prefix.
• Arguments must be structs. To allow the extension of existing components, multiple arguments can be accepted.
• Templ provides props for all HTML elements (I guess this can be generated from the specs).
• Arguments are validated at build time (limited) and debug mode (not sure how golang handles this).

About the naming of components

I guess it might be tricky to find out if a component is actually a native HTML component or custom component. An easy solution would be to prefix the components with the package name:

<app:button />

It could also be helpful to be able to override the existing HTML buttons, but there are also arguments against that.

[joerdav]

Not a stupid question at all, when we designed the templ element expression syntax we did consider a syntax such as what you have suggested.

This is the syntax we landed on: https://templ.guide/syntax-and-usage/template-composition

The reason we went with this over something more familiar to HTML, was to reduce the complexity of the implementation, and make the interaction with the go lsp easier (because it looks like a go function it's much easier for the auto complete in IDEs to work.

Hopefully this explanation helps you understand the thought process a bit!

[SebastianStehle]

I have read this page and I think the current syntax is great for things like headers or higher order components, that render entities like products or something like that. But components like buttons and so on tend to have a lot of attributes and I think it would make the refactoring and code a lot easier if you could build components with a xhtml syntax.

I don't know how other developer use templ, but lets say you are really working with fine grained components then your template would not look like html at all.

e.g.

from this

<section>
   <h1>Header<h1>
   <button type="submit">Hello</button>
</section>

to

@Section() {
   @HeadingH1() {
      Header
   }
   
   @Button(templ.Attributes{"type": "submit"}) {
      Hello
   }
}

Would it not be nice to just have something like this?

<app:section>
   <app:heading>Header<app:heading>
   <app:button type="submit">Hello</app:button>
</app:section>

[PaluMacil]

I think it would be nice, but at the same time it would probably need to be a different framework. It's a different approach that I would enjoy trying, but I'm not sure I'd want something with so much overlap to current functionality in the same framework

[SebastianStehle]

Where do you see a disadvantage? I think it is always a good goal to have a simple consistent syntax, but the new approach has a lot of advantages:

1. Easier templates, because there are less syntax elements if you only use components.
2. Faster, because you do not have work with maps for attributes.
3. Easier to handle many parameters, because Go does not have named or optional function arguments.
4. Safer, because you can leverage validation.
5. Better developer experience, because due to build validation you will see errors early.

I understand that it might be tricky to implement. Because of the structs and inherited properties we need build information from golang. e.g. which fields are available on the structs. I am not sure if you already have that in the build process.

[joerdav]

I can definitely see the advantages, here's some other points for consideration though:

• Would this syntax conflict with any valid web components? (I don't think so, looks like custom components can't have :)
• Would this syntax be more familiar for new developers, than a go like function?

[SebastianStehle]

• If you use XHTML namespaces you could end in conflicts, but otherwise I don't think so.
• Not sure. Depends where they are coming from. if you are a SPA developer (angular, react ...), probably not ;)