🚀 [Feature]: Templ support?

[mamereu]

Feature Description

Any plan to include templ support ?

Additional Context (optional)

No response

Code Snippet (optional)

package main

import "github.com/gofiber/template/%package%"

func main() {
  // Steps to reproduce
}

Checklist:

• I agree to follow Fiber's Code of Conduct.
• I have checked for existing issues that describe my suggestion prior to opening this one.
• I understand that improperly formatted feature requests may be closed without explanation.

[ReneWerner87]

Not really, this concept is very different from the common template engins
Believe it does not offer much added value to encapsulate it

[luv2code]

I would like to see this too, but I'm not sure how it could be done in this repo because of the way go templ works. There needs to be a fiber->templ connector that is specific to the individual project's templ functions. I went down the path of making one.

The fiber view engine interface isn't complicated:

type Views interface {
	Load() error
	Render(io.Writer, string, interface{}, ...string) error
}

Load() is called when the fiber app is first initialized. Render is called inside the request. The parameters are: the output stream, the name of the template, the binding, the rest of the layout names.

To connect this with go templ, you need a struct with these methods implemented to call your templ functions. I would put it in the same package as the templ functions for convenience.

func NewTemplEngine() *TemplEngine {
    return &TemplEngine{}
}

type TemplEngine struct {
}

func (te *TemplEngine) Load() error {
    return nil
}

func (te *TemplEngine) Render(res io.Writer, templateName string, binding any, layouts ...string) error {
    return nil
}

You can pass this to the fiber app like:

package main

import "your/app/views" // your templ dir
import "github.com/gofiber/fiber"

func main() {
    app := fiber.New()

    app := fiber.New(fiber.Config{
        Views: views.NewTemplEngine(),
    })
    app.Get("/", func(c *fiber.Ctx) error {
        return c.Render("Greeter", "World")
    })
    app.Listen(3000)
}

This will run, but it won't render anything. We have to marry the Greeter template name with the Greeter templ function.

Define our greeter templ:

package views

templ Greeter(name string) {
  <span>Hello, { name }!</span>
}

We need to alter our Render function so that it calls the right templ function:

func (te *TemplEngine) Render(res io.Writer, templateName string, binding any, layouts ...string) error {
    switch templateName {
        case "Greeter":
        // coax our binding into the Greeter's string param type:
        name, _ := binding.(string)
        // call the templ function to get it's renderer
        templRenderer := Greeter(name)
        // render  the templ function to the output stream
        return templRenderer(context.Background(), res)
        default:
        return errors.New("template not found: " + templateName)
    }
    return nil
}

I think for it to be frictionless, there needs to be an additional tool that generates this code from the templ generated files. It makes more sense to me to put that in the github.com/a-h/templ project or make it independent from both projects.

If you really want to use templ in your fiber projects, I think it's a bit easier just to call the templ function in the fiber handler, and let templ do your layout:

func renderTempl(c *fiber.Ctx, cmpnt templ.Component) error {
	content := new(bytes.Buffer)
	cmpnt.Render(c.Context(), content) // maybe cmpnt.Render(c.UserContext(), content) ???
	c.Set("Content-Type", "text/html")
	return c.Send(content.Bytes())
}

app.Get("/", func(c *fiber.Ctx) error {
	return renderTempl(c, views.Greeter("World"))
})

[andradei]

The following is working for me. Is it a good enough solution?

package main

import (
	"log"

	"github.com/a-h/templ"
	"github.com/gofiber/fiber/v2"
	"github.com/gofiber/fiber/v2/middleware/adaptor"

        // This is the folder/package where `templ generate` puts the final templates on my project.
	t "github.com/my/webdev-examples/template"
)

func main() {
	app := fiber.New()

	app.Get("/", render(t.Home()))

	log.Fatal(app.Listen(":3000"))
}

// Use the Fiber adaptor middleware to turn a templ Handler into a fiber one.
func render(c templ.Component) fiber.Handler {
	return adaptor.HTTPHandler(templ.Handler(c))
}

[luv2code]

Thanks. I didn't know about adaptor.HTTPHandler. I like your solution.

How would you handle this?

templ Greeting(name string) {
       <p>{name}</p>
}

func main() {
	app := fiber.New()

	app.Get("/greeting/:name", render(t.Greeting("the :name parameter somehow?")))

	log.Fatal(app.Listen(":3000"))
}

[andradei]

@luv2code I ran into that right after I posted the simple solution above. I haven't found a solution that's not over-engineered yet, let alone reach a simple and elegant one.
So your solution is better and more complete. Although I hope for better fiber support that makes the solution simpler and more elegant.

[a-h]

Hi folks, author of templ here, since the ctx type implements io.Writer this also works.

package main

templ Hello(name string) {
	<div>{ name }</div>
}

package main

import (
	"log"

	"github.com/gofiber/fiber/v2"
)

func main() {
	app := fiber.New()

	app.Get("/:name", func(c *fiber.Ctx) error {
		c.Set("Content-Type", "text/html")
		return Hello(c.Params("name")).Render(c.Context(), c)
	})

	log.Fatal(app.Listen(":3000"))
}

But... I'm not experienced with Fiber, so I don't know what the best approach is.

There's another suggestion here: a-h/templ#349 (comment)

I would happily take a PR for a Fiber example, once we have consensus on best performance and nicest code. 😁

@luv2code - it shows how to use c.Params to grab the parameter from the URL.

[bastianwegge]

Thanks. I didn't know about adaptor.HTTPHandler. I like your solution.

How would you handle this?

templ Greeting(name string) {
       <p>{name}</p>
}

func main() {
	app := fiber.New()

	app.Get("/greeting/:name", render(t.Greeting("the :name parameter somehow?")))

	log.Fatal(app.Listen(":3000"))
}

@luv2code you'd only need to abstract the adaptor into a render function and use it. This would also allow to pass status-codes to your render function.

func main() {
	app := fiber.New()

	app.Get("/", func(c *fiber.Ctx) error {
		name := c.Params("name")
		return Render(c, GreeterView(name))
	})
	app.Use(NotFoundMiddleware)

	log.Fatal(app.Listen(":3000"))
}

func NotFoundMiddleware(c *fiber.Ctx) error {
	return Render(c, NotFoundView(), templ.WithStatus(http.StatusNotFound))
}

func Render(c *fiber.Ctx, component templ.Component, options ...func(*templ.ComponentHandler)) error {
	componentHandler := templ.Handler(component)
	for _, o := range options {
		o(componentHandler)
	}
	return adaptor.HTTPHandler(componentHandler)(c)
}

I think integrating this into fiber will not be necessary. Something like return c.Render("Greeter", "World") where "Greeter" would be the component and "World" would be the argument(s) would ignore the benefit we have from templ generated go files.

[luv2code]

I would happily take a PR for a Fiber example, once we have consensus on best performance and nicest code. 😁

I like @bastianwegge 's solution, and I nominate that for use in a fiber-templ integration example PR.

[a-h]

Agreed. It looks great. 😀

[andradei]

@bastianwegge, that's working great! I think it can be simplified even further, unless there is a reason I'm not seeing for not doing so:

func Render(c *fiber.Ctx, component templ.Component, options ...func(*templ.ComponentHandler)) error {
	componentHandler := templ.Handler(component, options...)
	return adaptor.HTTPHandler(componentHandler)(c)
}

This is because templ.Handler takes a variadic ...options and does the same thing in an internal loop:

Which is:

func Handler(c Component, options ...func(*ComponentHandler)) *ComponentHandler {
	ch := &ComponentHandler{
		Component:   c,
		ContentType: "text/html",
	}
	for _, o := range options {
		o(ch)
	}
	return ch
}

cc: @a-h, @luv2code