Remote Functions: form validation

[Rich-Harris]

If you're passing arguments to query and command remote functions, you're required to provide a Standard Schema for validation, but no validation is required for a form.

This caused many of you — justifiably — to raise eyebrows. The rationale was that the type of the argument is always going to be a FormData object, and you can't type the contents of a FormData object (it's not generic), so you're going to have to do the validation inside the callback anyway. But it's clearly not ideal.

Following on from a lengthy conversation on the original discussion, this is a proposal to make form validation built-in.

Conversion

The first step is to convert the data to an object that can be validated. In the basic case...

<form {...login}
  <label>
    Username:
    <input name="username" />
  </label>

  <label>
    Password:
    <input name="password" type="password" />
  </label>

  <button>log in</button>
</form>

...this is easy — just create a { username: string, password: string } object. What makes it a little trickier is that fields can be repeated...

<label>
  <input type="checkbox" name="modifications" value="spicy" />
  Make it spicy
</label>

<label>
  <input type="checkbox" name="modifications" value="guac" />
  Add guacamole
</label>

...in which case you need to call data.getAll('modifications') on the resulting FormData object. The wrinkle is that it's not possible to know, from the server's perspective, whether modifications is supposed to be a string or a string[] in the case that there's only one checked value.

We can side-step that problem by disallowing duplicate fields and using syntax to denote arrays:

-<input type="checkbox" name="modifications" value="spicy" />
+<input type="checkbox" name="modifications[]" value="spicy" />

On the server, we can 'hydrate' these into arrays:

const data = hydrate(await request.formData());
// { protein: 'chicken', beans: 'pinto', modifications: ['spicy'] }

form.issues and form.input

Armed with this, we can validate your data and report issues back to the client, along with the submitted data, in a structured way:

<form {...login}
  {#if login.issues?.username}
    {#each login.issues.username as issue}
      <p class="error">{issue.message}</p>
    {/each}
  {/if}

  <label>
    Username:
    <input name="username" value={login.input?.username} />
  </label>

  {#if login.issues?.password}
    {#each login.issues.password as issue}
      <p class="error">{issue.message}</p>
    {/each}
  {/if}

  <label>
    Password:
    <input name="password" type="password" />
  </label>

  <button>log in</button>
</form>

You could of course build opinionated abstractions around this:

<Form handler={login}>
  <Input name="username" />
  <Input name="password" type="password" />

  <button>log in</button>
</Form>

Reactivity

myForm.input would be updated on input events, allowing you to express relationships between form controls:

<form {...myForm}>
	<input type="range" name="min" max={myForm.input.max} />
	<input type="range" name="max" min={myForm.input.min} />

	<button>submit</button>
</form>

Types

issues is a Record<string, Issue[]> where Issue comes from Standard Schema. Each issue has a message and a path property.

input is a Record<string, FormDataEntryValue>. (Not 100% sure yet what would happen in the case of an <input type="file">.)

Rolling up issues

Issues belonging to members of arrays are rolled up to the arrays themselves — in other words, to take our earlier food ordering example, issues.modifications would include any issues belonging to modifications[0], etc. The issue.path can be used to distinguish between them.

issues.$ could be a place to put root-level issues, and a rollup of all the issues found while validating.

Manual validation

Since validators can be async functions, and since you can use getRequestEvent inside those functions, it should be possible to do the bulk of your checking inside your schema. As a bonus, if you have multiple async checks they will happen in parallel.

There are some cases where you don't know if data is valid until you attempt to perform some action. In these cases, you might still want to report a validation error (populating issues and input) rather than returning or erroring. For that reason, we will probably need to provide a method for populating issues programmatically:

const createPost = form(schema, async (data, invalid) => {
  // if we're here, then so far no issues have been found by the schema
  try {
    await db.post.create({
      title: data.title,
      content: data.content
    });
  } catch (e) {
    if (e.code === 'CONFLICT') {
      // this throws an error that causes `createPost.issues` and `createPost.input` to be populated
      invalid({
        title: 'A post with this title already exists'
      })
    }

    throw e;
  }
});

invalid would be typed such that you could only use keys matching the schema. It throws an understood-by-SvelteKit error, so as not to pollute the type of the return value — in other words, returning always indicates success. A non-invalid error would cause the error page to appear, and thus should be avoided.

Client-side validation

Validation is server-first, but you can add client-side preflight validation, and you can trigger validation programmatically to populate issues before the form is submitted.

Preflight validation, like server validation, accepts a Standard Schema:

<script>
  import { login } from '$lib/auth.remote';
  import * as z from 'zod';

  const schema = z.object({
    email: z.email(),
    password: z.string().min(8)
  });
</script>

<form {...login.preflight(schema)}>
  <!-- ... -->
</form>

Now, before the form is submitted to the server, it will be checked against the preflight schema. If it fails to validate, login.issues will be populated. If it does validate, it will then be submitted so that you can validate the data on the server. This may involve the same schema (exported from a shared module, since you cannot export a schema from a .remote.ts file — you can only export remote functions), but in many cases the server-side validation will include additional checks.

Separately, you can programmatically validate the form on demand with the validate method. You can call this whenever you like, for example after an input is blurred:

<form {...login} onfocusout={login.validate}>
  <!-- ... -->
</form>

This will validate the data and populate login.issues, but it won't submit. By default, issues relating to controls that aren't yet dirty (i.e., they haven't been interacted with) would be omitted.

Wrinkles

• Do we run preflight checks when calling login.validate? That would allow us to give immediate feedback, but it would also prevent server validation from occurring if the form was incomplete — for example in a registration form we wouldn't be able to check if username was already in use until password had already been filled out.
• For the proposed preflight and validate APIs to work, we need a 1:1 correspondence between <form> and form function. (<form> follows function, heh.) This is easy enough to implement with an attachment, and if you need multiple instances you can use form.for (which we need to get around to documenting), but are there situations in which this would be restrictive, perhaps around buttonProps?

Security

So far this proposal assumes that it's safe to return submitted data back to the user in case of a validation error. This gets slightly murky around things like passwords and credit card info.

The conventional wisdom on this seems to be that it is safe — if you trust everything between the browser and the server (which you have to in order to do anything) then it stands to reason that you can trust everything between the server and the browser.

But it deserves careful scrutiny. Does having your password in the HTML of the response (even if in a JSON object rather than the markup) create vulnerabilities that aren't already present? (Obviously if a bad actor has access to your computer, they can get your password from the HTML, but they could already have installed a keylogger or inspected input.value, so that's not a new vulnerability.) Given that POST requests aren't cached, I would like to imagine it doesn't. I hope that the AI companies currently threatening us with new browsers, so that they can crawl more content without having to circumvent anti-bot measures, are careful enough not to add POST responses to their training data.

It's probably fine, but I'd love for people to share their thoughts on this!

[eltigerchino]

In the general case you can't use the same schema on both sides, because your server-side validation is likely to rely on database calls etc, so any attempt to make things reusable would likely create more problems than it solves.

I tried solving this in a pet project by having a base schema (shareable between server and client), then extending it for a client-specific schema and a server-specific schema. The server schema would, like you said, make database calls, while the client schema would send requests to the server (like checking if a username is taken before we submit the registration form). I wonder if there's some magic that can happen here where we add a query remote function inside a schema and that just becomes a function call on the server but a fetch in the browser.

[anvimaa]

This is exactly why Svelte keeps showing who’s boss in the market. While other frameworks drown developers in boilerplate, SvelteKit is pushing forward with native, typed, and integrated form validation that solves a real DX pain point cleanly. Turning FormData into typed objects, supporting arrays and nested properties out of the box, and returning structured issues and inputs is nothing short of a game changer. Once again, Svelte proves it’s one step ahead: simple on the surface, powerful underneath.

[ottomated]

No client-side validation

I don't think this is a dealbreaker for me in particular, but the success of superforms indicates that it's an important feature for many people. I don't think myForm.validate is good enough because it still involves a server round-trip.

My question is: which is more valuable, the ability to put server-specific validations inside your schema, or the UX improvement of instant client validation? I think the clear answer is the latter.

Server-side validation pros:

• can avoid using invalid in most cases
• async operations in parallel by default

Cons:

• complicated validations are harder to write inside a schema than outside

Universal validation pros:

• No additional dev work required to instantly validate
• snappier user experience
• possibility of integrating remote queries

Cons:

• harder implementation
• requires an opt-out option

[ottomated]

I imagined a vite step like this (similar to comptime.ts)

const password = z.string().min(8);

export const login = form(z.object({ username: z.string(), password }), () => {});

↓

// client-side
export const login = async function () {
  let schema;
  {
    // walk the AST to determine all variables referenced in the schema and copy them here
    const password = z.string().min(8);
    schema = z.object({ username: z.string(), password });
  }
  // other stuff
  // validate schema client side
  await fetch('/_app/...');
};

[saturnonearth]

Be aware that the client doesn't have access to the schema. At a bare minimum you need to do something like this — importing the universal schema from a third module:

I think allowing the ability to have framework supported client/server validation would be huge, and the icing on the cake, but not a dealbreaker - any validation is a win. But I do think keeping the 2 together makes the most sense, as the least trips to the server the better.

Does anyone have ideas for an API that doesn't suck? (And is possible to implement, ideally)

I am not sure if this helps at all with what you are asking, but I know that Fabian Hiller is working on adapting Svelte to formisch - which is a lightweight form validation library. I wonder if it could be integrated in some manner?

[AndreasHald]

This seems like a very acceptable compromise to me

<script>
  import { Credentials } from './schema.ts';
  import { login } from './auth.remote';
</script>

<form {...login.withSchema(Credentials)}>
  <!-- ... -->
</form>

you could even argue that it's "too" opinionated, because then a good question become when do you validate the data against the schema?

• on each change of the data?
• in the oninput event handler on the form?
• in the onchange event handler on the form?
• on blur in the onfocusout event handler on the form?

You could also argue for an even simpler api like this

<script>
  import { Credentials } from './schema.ts';
  import { login } from './auth.remote';
</script>

<form {...login} oninput={() => login.validate(Credentials)}>
  <!-- ... -->
</form>

The tradeoff being that then you have to call the validation yourself but offers flexibility in when it's called - If you wan't to standardise it within your codebase you could just ship a form component that takes a remote form and a schema and does it for all your forms.

[saturnonearth]

The tradeoff being that then you have to call the validation yourself but offers flexibility in when it's called - If you wan't to standardise it within your codebase you could just ship a form component that takes a remote form and a schema and does it for all your forms.

I agree, the validation should be a base set of functions that can be easily controlled to the user's liking. "Choose your flavor".

[ottomated]

@Rich-Harris I've been thinking and experimenting about how to automatically get access to the schemas on the client. With scope analysis a lot should be possible, but the question is how much should be allowed.

It shouldn't be all referenced variables, because this could leak secrets:

import { z } from 'zod';

const CONFIG = {
  passwordLength: 8,
  secretKey: 'this gets leaked',
};
form(z.object({ password: z.string().min(CONFIG.passwordLength) }));

Maybe a good compromise is only allowing referencing variables from imports? The example above could throw an error like Cannot reference a local variable "CONFIG" inside a form validation schema.

Even then, hypothetically this could happen to cause a desync:

import { z } from 'zod';

z.string = z.number;

form(z.object({ password: z.string() }));

I'm guessing static analysis isn't enough to detect mutated imports like this, but it does seem like a pathological case - maybe it could be detected at dev-time?

I do think an invisible api like this, if it's possible, would be pretty unparalleled DX.

[ottomated]

Maybe this could solve confidential data being returned in inputs?

export const myForm = form(
  z.object({ password: z.string() }),
  () =>{},
  {
    protectedInputs: ['password']
  }
);

[ottomated]

I really want a type-safe <input name={myForm.name('username')}> and

const { form, name }: {
  form: TForm,
  name: FormInputName<TForm>
} = $props();

[PatrickG]

How about myForm.names of type string[] (or rather ('username' | 'password')[])?
Or myForm.fields of type { username: { type: 'text', ... }, password: { type: 'password', ... }} (But for that we would need something like Superforms constraints)

[ottomated]

When would those proposals be useful? I want to solve the case of typoing field names

[AndreasHald]

I would really like this too, it would catch so many errors. it could even just be a typescript wrapper but you would have compile time validation

loginForm.getName(name: 'username' | 'password') {
   return name
}

[PatrickG]

When would those proposals be useful? I want to solve the case of typoing field names

Yea, myForm.names would not help with <input name={???} />, but this

const { form, name }: {
  form: TForm,
  name: FormInputName<TForm>
} = $props();

could be written like this:

const { form, name }: {
  form: TForm,
  name: TForm['names'][number]
} = $props();

---

With myForm.fields, you could do

<input name={myForm.fields.username.name} />
<!-- or --> 
<input {...myForm.fields.username} />

[ottomated]

issues.$ could be a place to put root-level issues, and a rollup of all the issues found while validating.

I do think there needs to be a way to list just the root-level issues somewhere, if I'm already displaying the field-level issues next to each field.

[Rich-Harris]

issues.$.filter((issue) => issue.path.length === 0)

[ottomated]

I suppose... wouldn't this balloon the response size? Or are you thinking the issues would get consolidated on the client?

[wiesson]

I'm using this small lib for this: https://github.com/fabian-hiller/decode-formdata. Maybe it can help as inspiration (or just use it directly)

[Rich-Harris]

It's a cool library but we definitely can't use it directly, since it requires that you pass in the metadata at the callsite and there is no callsite. It also doesn't handle the blah[] syntax. Personally I think it's better to just do the coercion/transformation in the validator

[jdgamble555]

This would be awesome! This is one of the best things about Angular that is is unique: Angular Forms. However, instead of reinventing validation, you allow Zod, Valibot, etc. So, my 2c would be for this to work both in Server Actions and in vanilla Svelte.

J

[sillvva]

Remote functions is a kit thing, not a vanilla svelte thing.

[jdgamble555]

Understood, but why not allow client side Validation too. Superforms allows both. Either way, server side is better than manual validation.

[aurorarissime]

Would love to see both server and client side validation!!

[alexbjorlig]

Same here - for many simple forms it's essetial to have a simple schema that is validated both on client and server

[mateothegreat]

I hold to my core sincerity for the enormous amount of effort given to svelte — pushing the boundaries is what keeps this framework evolving. 👏 Let's 👏 go!

My ultimate fear is violation of the principles Svelte promises: the values that have defined its identity and trust with the community. These include (some are verbatim):

• Framework as a compiler — minimal runtime cost, most logic disappears at build time.
• HTML‑first mindset — enhance native web technologies rather than replace them.
• Simplicity first — minimal boilerplate, intuitive syntax, small API surface.
• Magical, not magic — delightful features that remain understandable and debuggable.
• Alignment with the platform — lean on FormData, fetch, and the DOM where possible.
• Progressive enhancement — core functionality works; enhancements are opt‑in.

The loser in this equation could be measured in the impact compromise has overall, in the long run.

That said, baking form validation directly into form functions at the framework level risks creating expectations the core can’t sustainably meet.

Once SvelteKit ships with a parsing + Standard Schema pipeline (or similar), it’s reasonable for developers to assume:

• Every edge case will be handled (nested shapes, array coercion, sanitization, dot/array notation quirks, etc.).
• It will work seamlessly with any schema library or API convention.
• Echoing submitted data back to the client is safe because Kit manages it — even though the proposal itself notes this "probably" deserves more scrutiny, so it’s worth underlining again.

That’s a large, ongoing surface area for a framework built on small, predictable primitives and an ethos of:

• Minimal magic: primitives over heavy abstractions.
• Progressive enhancement: forms should work without JS, with enhancements opt‑in.
• Unopinionated data handling: developers choose how to parse/validate.
• Alignment with the platform: embrace FormData, fetch, etc., unless abstraction is a clear universal win.

The proposal cuts across those lines by:

1. Coupling form to a single schema system, reducing flexibility for Zod, Valibot, Yup, or custom logic.
2. Replacing the raw FormData contract with opinionated object transformation and key‑flattening.
3. Risking divergence between enhanced and plain form behavior.
4. Imposing a data‑shape decision that can hinder integration with existing APIs.
5. Building in security/privacy assumptions that are impossible to hold in all environments.

If we must, an idiomatic path forward could be that we keep form’s core contract as FormData in -> { success, errors } out, and ship optional helpers/adapters (Standard Schema, Zod, Valibot, etc.) for those who want them.

This would preserve SvelteKit’s "small core, powerful primitives" DNA, avoids inheriting every parsing/validation edge case, addresses the assumptions problem, and still makes the happy path easy for those who opt in.

✌️

[jdgamble555]

I respectfully disagree with this. Remote functions is already shipping the ability to do custom validation (zod, valibot, etc)... whether or not it should is a different question, but the overhead for that is already there. I don't think anyone expects every edge case to be handled. SvelteKit itself certainly doesn't do that, but there is always a reasonable middle ground with any feature.

I think you can see the usefulness when you look at what tanstack does, solidstart, qwik, etc... there is a need for this, and the majority of people will definitely find it useful. SvelteKit is a compiler... I say get rid of the painful things in JS that can be simplified, or at least make them optional. Maybe just a built in function for the formData like superforms does if we don't want to make this built-in, but 99% of the time, people will use it to get rid of boilerplate.

J

[Rich-Harris]

Progressive enhancement: forms should work without JS, with enhancements opt‑in

Everything I talk about here is 100% compatible with progressive enhancement

Alignment with the platform: embrace FormData, fetch, etc., unless abstraction is a clear universal win.

No one likes working directly with FormData. What possible benefit is there?

Coupling form to a single schema system, reducing flexibility for Zod, Valibot, Yup, or custom logic.

It uses Standard Schema. All the libraries you mention support it!

[mateothegreat]

I appreciate the intent to improve DX, but the original strength has always been clarity and neutrality — a minimal, schema‑agnostic contract can embody Svelte’s small‑core DNA.

In this proposal, we are moving to “prescribed parsing into nested objects, schema‑driven validation, and opinionated return shapes (issues, inputs)”. These are undeniably useful in isolation, but they are, by definition, a departure from the minimalism that has been central to Svelte’s identity.

The way I see it is that when the core changes in this way, it isn’t just an ergonomic gain — it’s an architectural shift. Once inside form(), these behaviors are no longer optional in spirit; they set new expectations the framework must meet indefinitely, binding the API to one style of parsing, shaping, and validating.

The right balance can be clear: keep the lean core contract intact, and ship parsing/validation as first‑class, opt‑in helpers. This preserves flexibility for any schema tool, offers zero‑boilerplate wins to those who want them, and safeguards the principles — minimal magic, platform alignment, unopinionated data handling — the substance that makes up the earning of the community’s trust.

Simplicity isn’t an aesthetic preference here; it’s the safeguard against complexity creep. Should there be compromise on it? Possibly.. when there’s an unambiguous, mass‑level benefit that serves everyone—absolutely. I just took the opportunity to ground things on the premise of principle as it’s overlooked now’a’days in most contexts. I greatly appreciate that this is an open discussion for anybody to chime in on. Keep up the amazing work!

[ollema]

The way I see it is that when the core changes in this way, it isn’t just an ergonomic gain — it’s an architectural shift.

I disagree - I think this is a huge ergonomic gain and not an architectural shift. but that is just my opinion

[eddiemcconkie]

Maybe they can make form validation opt-in. If you pass a schema to form(), it gets validated. If you don't pass in a schema, it gives you the FormData to validate manually for when you need something more customized.
I've seen some other comments about type-safe input names and client validation, but it seems like it would be easy to opt in to those as well, and for those who don't want it, it still works perfectly fine with <input name="whatever">

[peterreeves]

Overall, looks good!

Opt out

To opt out, I assume if you omit the schema argument, the callback you passed to form receives a FormData? (i.e. the current behaviour)

Client-side validation

No client-side validation feels like a very bad downside. I get that some people want to wrap database calls inside their validation (which I think conflates two different things), but being able to do basic data validation in the form while the user is filling it out is what I would prefer. It's much nicer to be told about an error immediately as opposed to filling out the entire form, scrolling down, hitting submit, and then seeing errors.

The manual myForm.validate(form) you mention, where would you put that? Would I call it in my input's onchange callbacks? I assume it would populate the form.issues? I don't know how you'd omit errors for fields that the user hasn't filled out yet though (Filling in the first field of a form and having the rest of the form explode with errors about fields you haven't yet gotten to would be a bad user experience).

[jdgamble555]

Yeah, I think if there is a way to opt-out by not using a schema it would appease almost everyone and use case.

[AndreasHald]

What would the api look like for populating a form with data? would inputs just be a $state() rune?

<script lang="ts">
  updateUser.inputs = await getCurrentUser();
</script>
<form {...updateUser}
  <label>
    Username:
    <input name="username" bind:value={updateUser.inputs?.username} />
  </label>
  ...
</form>

[brandonpittman]

I was the person who set off the thread this discussion spun out from.

I'm stuck using a third-party library to do client-side validation. As much as I'd like to rely on server-only validation, designers request experiences that require client-side validation. It's a deal breaker not to have client-side validation, and it was the impetus for my original comment.

I need to be able to revalidate input, on input, and I need to manipulate the UI (button states, etc.) based on the validity of the form.

[Rich-Harris]

Does that require client-side validation, or merely the ability to validate without submitting?

[shivan-s]

Not a dealbreaker if it's server-side only. In fact, feeling very guilty to have this much good DX.

[saturnonearth]

Not a dealbreaker if it's server-side only. In fact, feeling very guilty to have this much good DX.

Lol so true, I feel at some point we are being spoiled, and we obviously don't want a framework to solve every problem;the recent changes to svelte/kit have been amazing. But this does feel like client and server validation go hand-in-hand, is such a QOL thing.

Imo, the best security, DX, and UX, is consistency. We all just want to build nice UI and experiences, and want our frameworks to give us the tools to do so. Forms and in general, schema validation, has been shown a lot of love in the last couple years, I'm just happy to be here, seeing this discussed.

[GauBen]

Hi there! I'm the maintainer of formgator, a FormData validation library used by checks notes fcrozatier and I. I'd love to see native form validation built into SvelteKit, so here's what I learned along the way:

• Don't try to understand a FormData object without a schema.

  The first step is to convert the data to an object that can be validated. In the basic case... this is easy.

  It's not, FormData objects are weird. For instance, an <input type="checkbox" /> can produce two outputs:

  // Checked
  data.get('checkbox') === 'on'
  
  // Not checked
  data.get('checkbox') === null

  My recommendation is to never try to guess the intent (checkbox, select multiple, radio...), but have an explicit schema instead:

  import * as fg from 'formgator';
  
  const schema = fg.form({
    username: fg.text(), // Different kinds of <input />s
    age: fg.number(),
    newsletter: fg.checkbox(),
    picture: fg.file(),
  });

  Thanks to this, we can properly type newsletter as a boolean, age as a number, picture as a File...

• Don't automatically nest/array-ify values, it may create vulnerabilities. For instance, if letter[] is automatically transformed into an array under the letter name, the following can happen:

  // <input name="letter" value="a" />
  letter.length === 1; // I'm a single letter!
  // <input name="letter[]" value="oops" />
  letter.length === 1; // I'm an array with a single element

  Also it may be weird to have <select name="one"> but <select multiple name="many[]">, but that's my opinion

• Regarding issues and reflected data, not much to say, it's really close to my implementation

  Same for invalid, but I named it formfail

• Server-side validation should re-perform client-side validation. For instance minlength and things like that.

  I also believe that a schema is not the right place to place db calls or other async constraints. It's meant to be used as a network boundary, not to contain business logic. This position makes "universal" schemas easier to share between front and back.

[Rich-Harris]

• For instance, an <input type="checkbox" /> can produce two outputs:

How do you handle the ambiguity in a case like this — if on is checked is is lights: true or lights: ['on']?

<label>
  <input type="checkbox" name="lights" value="on" /> on
</label>
<label>
  <input type="checkbox" name="lights" value="dimmed" /> dimmed
</label>

• For instance, if letter[] is automatically transformed into an array under the letter name, the following can happen

The combination of letter and letter[] would be disallowed, which IIUC prevents the situation you describe

[GauBen]

How do you handle the ambiguity in a case like this — if on is checked is is lights: true or lights: ['on']?

It all depends on the meaning you want to give to your form, and how you're expecting the data to be served to your backend:

1. You HTML is functionally equivalent to (as far as the server is concerned):

   <select multiple name="lights">
     <option>on</option>
     <option>dimmed</option>
   </select>

   So this would be your form schema:

   const schema = fg.form({
     lights: fg.select(
       ["on", "dimmed"],  // First parameter is the list of accepted values
       { multiple: true } // Second parameter is the modifiers on the <select /> element
     ),
   });
   
   // schema.parse() returns a { lights: Array<"on" | "dimmed"> } object

   Because it's a bit unusual to change the value of a checkbox, there is no fg.checkbox({ multiple: true }) API.

2. If you want two booleans instead of array, you could do this instead:

   <label>
     <input type="checkbox" name="lights-on" /> on
   </label>
   <label>
     <input type="checkbox" name="lights-dimmed" /> dimmed
   </label>

   Which is now parsable with this schema:

   const schema = fg.form({
     "lights-on": fg.checkbox(),
     "lights-dimmed": fg.checkbox(),
   });
   
   // schema.parse() returns a { "lights-on": boolean; "lights-dimmed": boolean; } object

3. And finally if you're still unsatisfied because you want both your original HTML (because you're using a third-party component maybe) and booleans, you can have that with fg.custom:

   // A custom validator for this specific form component
   const multiCheckbox = (...names) => fg.custom((formData, prop) => {
     const values = formData.getAll(prop);
     return Object.fromEntries(names.map(name => [name, values.includes(name)]));
   });
   
   const schema = fg.form({
     "lights": multiCheckbox("on", "dimmed"),
   });
   
   // schema.parse() returns a { lights: { on: boolean; dimmed: boolean } } object

   This is an escape hatch more than a feature, but it's there.

Here's a playground of all examples

The combination of letter and letter[] would be disallowed

That makes sense, but I'm more concerned about an attacker changing letter to letter[] so that the server gets an array when it expects a string.

[Rich-Harris]

an attacker changing letter to letter[] so that the server gets an array

But then validation would fail, unless your schema allowed both for some reason?

[GauBen]

Yes, no issue in the case where the data is validated by a schema

[Rich-Harris]

You would have to opt out of validation with 'unchecked', like for other remote functions

[Rich-Harris]

I've updated the original post with some designs around reactivity and client-side validation. You can read them up top, but tl;dr

• myForm.input.foo would get updated whenever <input name="foo"> emitted an input event
• <form {...myForm.preflight(schema)}> would prevent submission if the data didn't conform to schema
• myForm.validate() would validate the data on-demand, without submitting it. It would populate myForm.issues, excluding those belonging to controls that hadn't yet been interacted with

[ollema]

great to have client side validation included in this proposal! looks good IMHO

[AndreasHald]

I've updated the original post ...

Love the changes, it's everything I wanted, really excited for it.

I just wanted to confirm however that the inputs for the form are writable? for example if you wan't to programmatically update the elements?

<form {...createPost}>
  <label>
    Title:
    <input 
         name="title" 
         value={createPost.input?.title} 
         oninput={(e) => createPost.input.slug = sluggify(createPost.input.title)}
     />
  </label>

  <label>
    Slug:
    <input name="slug" value={createPost.input?.slug} />
  </label>

  <button>Create</button>
</form>

[Rich-Harris]

Or do you always need to specify it in any case?

You always need to specify it - never rely purely in client-side validation

I just wanted to confirm however that the inputs for the form are writable?

They could be, and in fact it would be easier from an implementation standpoint since we can then just use $state. Just a question of whether we feel it's important for the form controls themselves to be the single source of truth. I suspect making them writable would be a useful escape hatch though, so in summary, probably 'yes'

[saturnonearth]

You always need to specify it - never rely purely in client-side validation

For sure! For my current project most of my mutations are handled via a server-side PUSH endpoint via Zero, where validation can occur - but what I am wondering is..would you be able to validate client-side (and benefit from the niceities) even if we are not using remote functions?

[brandonpittman]

Looks great. I don't think Svelte needs to do more than this. Another userland lib could handle the rest of the client-side validation stuff.

[ziedHamdi]

Seems complex to read :-), as I don't have immediate needs, it's just distracting me, because it is interesting.
I would have put an interface/schema as an attribute to a svelte component named HydratedForm.svelte.

then every child comprennent would have a mapping property path to put the value in once hydrated client side. For example . Path is then used to construct the object out to read it to prefill the form.

This allows the validation to take place client and server side with the same code, and allows two way bindings

[abdelfattahradwan]

We will still be able to use form(async (formData) => ...) without any validation or FormData to object conversion, correct?

[Rich-Harris]

You can use 'unchecked' to bypass validation but it would always be converted to an object

[abdelfattahradwan]

You can use 'unchecked' to bypass validation but it would always be converted to an object

Would it be possible also to have a 'raw' option that neither validates nor converts the input? I believe the new behaviour would be a little problematic for codebases that already rely on form remote functions to only have FormData as their args, or if someone parses arrays/nested properties differently.

[Rich-Harris]

Making the API more complicated for the sake of people who opted into an experimental feature — clearly marked 'likely to contain bugs and is subject to change without notice' — would be a poor decision

[abdelfattahradwan]

Making the API more complicated for the sake of people who opted into an experimental feature — clearly marked 'likely to contain bugs and is subject to change without notice' — would be a poor decision

I understand 🙂 I was just wondering if it would be possible. It should be relatively easy to migrate when the new changes are out.

P.S. I don't care that the feature is "experimental" I work on apps that ship with 100s of remote functions 🤣 They are freaking awesome.

[Rich-Harris]

I work on apps that ship with 100s of remote functions 🤣

Absolute recklessness, I love it. The Svelte community is something else

[samuba]

This package enables client side validation for remote functions. It's interesting what people already come up with. Maybe this can inform some decisions for the official implementation.
(I'm not the author)

https://github.com/grauw-fr/faurm