templ and forms

[neilyoung]

I really like templ a lot and having played a lot with it lately.

I'm wondering if there is some GO-ish wiring between a form in templ and the backend.

What I mean is maybe illustrated by example: In order to parse form values during a POST I'm doing things like this:

r.ParseForm(); 
email := strings.TrimSpace(r.FormValue("email"))
password := r.FormValue("password")

This works of course, but I don't like much the mutual reference between form and backend by "names" of HTML elements, since one typo in templ or GO and the connection is lost. Is there some more idiomatic way to to this? Isn't there a way to let templ and backend share the same object?

One way could be to create a GO representation of the HTML elements which should be presented in the form and pass that as slice to templ, so that templ could dynamically render the form elements in order of their appearance with their attributes. But this seems to be a horrible overkill and could probably better pictured by other engines (like GOMPONENTs or so).

Any idea?

[joerdav]

I don't see anything being added to templ for this, as the way that someone communicates from their browser back to the server isn't templ's remit, and is very case dependent. For your use case, the solution maybe as simple as defining some constants in your code that can be used in both the template and the handler:

// handlers/handler.go
func ServeHTTP(w http.ResponseWriter, r * http.Request) {
    r.ParseForm()
    email := strings.TrimSpace(r.FormValue(templates.EmailValue))
    password := r.FormValue(templates.PasswordValue)
}

// templates/template.templ
const (
    EmailValue = "email"
    PasswordValue = "password"
)

templ Form() {
    // ...
    <input name={ EmailValue } />
    <input name={ PasswordValue } />
    // ...
}

[neilyoung]

Yes, thank. Constant would be one way. The other would be to define a "props" struct like in React

[a-h]

I've been meaning to write up some good form examples with templ, but haven't gotten around to it. I think it's a missing part in the docs.

I cover form validation a little in a talk I did at BigSky Dev Con 2024 - see https://templ.guide/media/

I think what you're describing is a bit like what you can do in ASP.NET MVC:

// Models/ViewModel.cs
using System.ComponentModel;

public class ViewModel
{
    [DisplayName("User Name")]
    public string UserName { get; set; }
}

// Controllers/HomeController.cs
using System.Web.Mvc;

public class HomeController : Controller
{
    [HttpGet]
    public ActionResult Index()
    {
        return View(new ViewModel());
    }

    [HttpPost]
    public ActionResult Index(ViewModel model)
    {
        if (ModelState.IsValid)
        {
            // Handle valid submission
        }

        return View(model);
    }
}

@model ViewModel

@using (Html.BeginForm())
{
    <div>
        @Html.LabelFor(m => m.UserName)
        @Html.TextBoxFor(m => m.UserName)
        @Html.ValidationMessageFor(m => m.UserName)
    </div>

    <button type="submit">Submit</button>
}

You can see that the view is strongly bound to specific fields on the model. It's hard to do something identical in Go, because it doesn't have the attribute system in C#, e.g. [DisplayName("User Name")] and the ability to use an expression m => m.UserName.

But, you can do something very similar by defining something similar:

type Field struct {
  Name string
  DisplayName string
  IsValid bool
  ValidationMessages []string
}

type ViewModel struct {
  UserName Field
}

And, your templ Page would then be...

templ Page(model ViewModel) {
  @mypackage.Textbox(model.UserName)
}

Where your mypackage has some templ components that take Field values in.

templ Textbox(field Field) {
   @LabelFor(field)
   <input name={ field.Name } value={ field.Value } />
  <!-- validation etc.. -->
}

templ LabelFor(field Field) {
  <label for={ field.Name }>{ field.Label }</label>
}

On the backend, you would need something to bind the request to the view model, i.e. something to work through the fields and ensure they were all populated.

All do-able, but not built-in to templ as a framework. Maybe an MVC framework would be handy, but templ is focussing on the UI layer at the moment.

[a-h]

By the way, if you wanted to write up some docs on forms, especially in conjunction with HTMX for dynamic loading of form sections, I'd be very happy! 😁

[neilyoung]

@a-h Thanks for your valuable comments. I'm currently buried in another project, but will return to this and give it a shot. Thanks

[a-h]

Oh, I forgot to mention that https://github.com/gorilla/schema can populate structs from form values. You don't need to get each form value individually from the request and wire it up yourself.

You'd probably want to write a unit test to ensure that the HTTP form <-> struct binding was populating all expected fields.

[neilyoung]

Nice find. Thanks for sharing

[a-h]

In #1240 I've put an example of a simple CRUD app.

Next, I plan to update the documentation to add a Forms section under Syntax and Usage in that PR.

[neilyoung]

Thank you very much

[neilyoung]

I like the way how you organize MVC. The current convention (having handlers here, views there, components again elsewhere and routes again somewhere scattered around) is highly confusing in larger projects. I like the idea to start it all from the route and have model, view, controller for a particular route in one folder side by side. Helps a lot to keep the overview.

What I don't fully understand is why you are having a model at all. I think, it is just half the way. Shouldn't the model abstract from the db? I would hold the db operations in the model too and pass instances of the model, not the db, as I see in the edit route (db.Contact passed).

Not sure, but I would treat the model as the glue and abstraction between controller and view.

But I'm not religious on that :) Thanks again for sharing

[joerdav]

It can be useful to decouple the db in this way, as then your frontend app isn't tied tightly to the way that you store things.

I like Bills demo on domain driven design that explains the value in this for growing projects: https://www.youtube.com/watch?v=bQgNYK1Z5ho

I modeled my example app on the ideas of the vid: https://github.com/joerdav/shopping-list

For my simple app it is overkill but you can see how it would scale.

[neilyoung]

@joerdav Thanks for the pointers. Watching the DDD video