Form Snippets or Macro Replacement

[enginewit]

Hey y'all. Thanks for making Sveltekit. It is amazing and I keep finding new cool things.
I recently ran across https://github.com/ciscoheat/sveltekit-superforms which works as a wrapper for ZOD. It uses one schema setup to validate both server and client side. It's very cool.
The only issue I have is the problem we all have with forms: a lot of boiler plate.
To get a fully functioning form input we need at minimum:

<label for='email'>E-mail</label>
    <input
      name="email"
      type="text"
      data-invalid={$errors.email}
      bind:value={$form.email}
      {...$constraints.email}
    />
    {#if $errors.email}<span class="invalid">{$errors.email}</span>{/if}
  </label>

when only the name and type need to be changed for different inputs.

I was thinking this could easily be reduced to a single line by creating a macro.js file which would export functions and return template literals. These would be run and replace the text in the file to be compiled, kinda like WTForms does for python in flask.

The way I envision it working, in pseudocode. We'd create whatever input types we need something like this...
macro.js

export function INPUT( fieldname, type) {
    let string = `<label for="${fieldname}">${fieldname}</label>
    <input
        type="${type}"
        name="${fieldname}"
        data-invalid={$errors.${fieldname}}
        bind:value={$form.${fieldname}}
        {...$constraints.${fieldname}}
    /> `
    return string;
}

In the +page.svelte file we'd add an import

import {INPUT} from './macro.js'
const { form, errors, enhance } = superForm(data.form); 

and it would be used like this

    <form method="POST" use:enhance>
	{@macro INPUT('$form.firstname', 'text')}
	{@macro INPUT('$form.lastname', 'text')}
	{@macro INPUT('$form.city, 'text')}
	{@macro INPUT('$form.password', 'password')}
	<div><button>Submit</button></div>
    </form>

If I do this as {@html INPUT('email', 'text')} it looks like it works but, of course, the data binding doesn't function. It runs the INPUT function and returns the string properly but doesn't do the second pass required to see the binding.

That's why I was thinking a pre-processor that would see the @macro and simply replace that line of code with the string literal before continuing to compile would be easy.

What do you think?

[oliversturm]

Wouldn't this work just fine with a normal component created along the lines of your INPUT? I feel I must be missing something.

[enginewit]

Unless I'm missing something, the bindings don't work. There's form, errors, and constraints. The bindings get lost using an INPUT.svelte.

[oliversturm]

Well I wouldn't say they get lost -- you'll need to pass them in, or drop them in a context so that the nested form elements can retrieve them.

But I guess I understand what you're asking: a macro system that would expand in the current context and enable boiler plate code like in your example without the need of a component structure. This does not exist.

If your form elements are sufficiently similar, perhaps you can stick your variable parts in a data structure and create the elements in a loop. Something like this:

const fields = [{
  email: {
    type: 'text',
    label: 'E-Mail'
  },
  somethingElse: {
    type: 'number',
    label: 'otherThing'
  }];

{#each Object.keys(fields) as field}
  <label for={field}>{fields[field].label}</label>
  <input
    id={field}
    name={field}
    type={fields[field].type}
    data-invalid={$errors[field]}
    bind:value={$form[field]}
    {...$constraints[field]}
  />
  {#if $errors[field]}<span class="invalid">{$errors[field]}</span>{/if}
{/each}

[enginewit]

Thanks for the reply but, yeah, that doesn't work for a multitude of reasons.

And I know the macro system I'm asking about doesn't exist but this being the "Ideas" area, I thought it was appropriate to suggest it as an update or future request. It's currently something Sveltekit doesn't do that would make forms much easier, less prone to typos, and prettier to look at. Sveltekit, as I see it, is about removing clutter and providing best practices for web development while leaving the user in charge of their design. The @macro idea does both in a way that is consistent with existing tools and doesn't require the passing of more data into more places. It's clean and elegant.

[oliversturm]

that doesn't work for a multitude of reasons

I understand that my suggestion may not cover all ideas implied by your proposal, but given your example I do wonder what reasons those are? I believe that my suggestion should certainly work for the scenario you described.