This is a continuation of the discussion in the remote function thread that expanded a bit beyond the scope of the remote functions implementation. So I wanted to lay out my thoughts, and spark a discussion about how complex native forms could be a first class citizen in svelte

Summation

Now that we have remote function forms (they have been out behind an experimental flag for ATLEAST a week, time to expand it). It revives the age old discussion of how do you handle more complex data.

Here it's worth mentioning a few points, svelte also implemented the command especially for this kind of thing and that you can actually do this with the current form implementation, you just have to handle deserialising the FormData yourself.

But I felt that there was enough positive discussion about other ways svelte could provide a standard for this that I wanted to examine my own thoughts on it a bit.

I think the general consensus from the discussion thread was that you could encode the structure of the object in the path names

So something like

 <input name="title" value="My title">
 <textarea name="content">My content</textarea>

 <input name="tag[]" value="foo" />
 <input name="tag[]" value="bar" />
 <input name="tag[]" value="baz" />

could be turned into

{
  title: 'My title',
  content: 'My content',
  tag: ['foo', 'bar', 'baz']
}

This pattern could also be used to represent deep data

<input name="article[0].tag[]" value="foo" />
<input name="article[0].tag[]" value="bar" />
<input name="article[0].tag[]" value="baz" />

{
  articles: [
     {
       tag: ["foo", "bar", "baz"]
    }
  ]
}

There was also a discussion of how form validation should be handled I believe the prevailing idea was to flatten all paths into a map so taking this html

 <input name="title" value="My title">
 <textarea name="content">My content</textarea>

 <input name="tag[]" value="foo" />
 <input name="tag[]" value="bar" />
 <input name="tag[]" value="baz" />

Could show errors like

issues = {
'title': 'Title is required',
'content': 'Content should be longer than x characters',
'tag[1]': 'Tag Bar already exists'
}

My thoughts

I think baking these features into svelte would create the possibility of really exceptional form handling, that could gracefully fallback for non js users, and it would incentivise developers to not always just fallback to command

I tried implementing some of my thoughts and while you can get pretty far in userland. But it wouldn't create the same level of standard as if svelte advocated directly for the path standard (ruby and PHP have similar patterns). it would also require a few tweaks to the current form implementation because atleast as far as I can tell it's not possible to do some things in userland (yet?).

This is one of the patterns I examined in quite liked

// add-person.remote.ts
const addPersonSchema = z.object({
	name: z.string().min(1, 'Name is required')
});

export const addPerson = validatedForm(addPersonSchema, async ({ name }) => {
	// db.sql(...)
	await getPersons().refresh();
	return 'success';
});

<!-- +page.svelte -->
<script lang="ts">
	const addForm = buildForm({
		remote: addPerson,
		data: { name: '' }
	});
</script>

<form
	{...addForm}
	class="mb-6 flex gap-2"
>
	<input
		type="text"
		name={addForm.getName('name')}
		placeholder="Name"
		bind:value={addForm.data.name}
	/>
	<button type="submit">
		Add person
	</button>
	{#if addForm.issues.name}
		<p>{addForm.issues.name}</p>
	{/if}
</form>

Some of the things that I really like:

• addForm.issues can be fully typed
• addForm.getName can provide a typesafe way of naming your inputs in accordance with the schema

Expanding on this pattern the buildForm function could also take a remote query as data instead of a POJO

// update-person.remote.ts
export const updatePersonSchema = z.object({
    id: z.coerce.number(),
    name: z.string().min(1, 'Name is required'),
    age: z.coerce.number({ error: 'Age is required' }).int().min(18, 'Age must be at least 18'),
    subscribe: z.coerce.boolean()
});


export const updatePerson = validatedForm(updatePersonSchema, async (personUpdate) => {
	db.update(...)
	await getPerson(personUpdate.id).refresh();
	return 'success';
});

export const getPerson = query(z.number(), (id) => {
	return db.select(...)
});

<script lang="ts">
	let { params } = $props();

	const form = await buildForm({
		remote: updatePerson,
		query: getPerson,
		args: Number(params.id)
	});
</script>

<form {...form}>...</form>

In this pattern we can populate the form with the query and update the state locally before submitting, taking advantage of the fact that a form submission would could utilise single flight mutations to re-populate.

Other considerations

We could optionally take the schema client side to do validation as you update the form on the client, as to not waste a roundtrip to the server to tell the user a name is required.

<script lang="ts">
	let { params } = $props();

	const form = await buildForm({
		remote: updatePerson,
		query: getPerson,
		args: Number(params.id),
                schema: updatePersonsSchema
	});
</script>

<form {...form}>...</form>

We could provide an api to do some validation on the server

// signup.remote.ts

export const signup = validatedForm(signupSchema, ({email, password}) => {
   const emailIsTaken = await db.select(..)
   if (emailIsTaken) {
     return validationError('email', 'this email is already taken');
   }
   ...
})

Some of the things that makes this tricky to implement in userland

• We could in userland work around the lack of a validationError method by returning the errors under a special key return {_issues: {...}} and grabbing that result client side. The http code would be wrong however, furthermore AFAIK it's not currently possible to refresh a query conditionally, so await getPersons().refresh(); would override our local form state because the form technically succeeded.