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!

[teemingc]

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.

[AlexRMU]

Client-side validation is all about speed and user experience. It runs in your browser to give you immediate, helpful feedback as you fill out a form, like pointing out a typo in an email address before you even hit "submit." It's meant to be quick and helpful, but it's just a suggestion because users can easily bypass it.
Server-side validation, on the other hand, is about security and integrity. It's the final and non-negotiable check that happens on the server after you submit your data. This is where the real rules are enforced, like checking if a username is already taken or if a request is legitimate. It has access to all the private data and business logic.
Because these two types of validation have such different goals - one for user convenience and the other for system security - a single, universal set of rules often isn't possible. They are two separate layers that work together to create an application that is both user-friendly and secure.

[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.

[shivan-s]

Sorry for being late to party. But agreed!

[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

[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

[x0k]

I already have an entity responsible for the state of the form on the client (issues and inputs are not used), and I would like to use form simply to send data to the backend, but I encountered the following problems:

pass converted data to enhance callback, rather than the FormData object

Now you cannot edit FormData before sending it (although in my case, I would prefer to create FormData from scratch).
I understand that this looks like an anti-pattern, because with JS disabled it will send different data, but that's how it needs to be.

---

		async function handle_submit(form, form_data, callback) {
			const data = convert_formdata(form_data);

			const validated = await preflight_schema?.['~standard'].validate(data);

			if (validated?.issues) {
				issues = flatten_issues(validated.issues);
				return;
			}

I also have an initialized validator that I would like to run before submitting the form

1. If you don't use enhance, then it will need to be adapted to the standard schema although I don't need to fill in issues
2. Time is spent executing convert_formdata even though I don't need this data

---

Compared to the backend version (with unchecked option), the client API feels much more opinionated.

---

This is not a problem at all, but I planned to use onsubmit from form to override some default handler: <Form {...form} />.
But now attachement is used, and this makes the integration a little less elegant.

[Rich-Harris]

You haven't given me an example. We're just going round in circles here, this is a very frustrating conversation. Show me a concrete use case that isn't handled with form

[x0k]

• does not support anything that doesn’t follow the field-naming convention (numeric properties, special characters in names, etc.)
• does not allow modifying FormData on the client to include metadata (optimization)
• does not allow transforming FormData -> POJO with metadata handling on the server
• adds memory and runtime overhead on the client when the issues and inputs properties are not used

[Rich-Harris]

Okay, then I'm satisfied that we don't need to do anything here because that's all fine:

does not support anything that doesn’t follow the field-naming convention

you can transform the object in the callback however you like

does not allow modifying FormData on the client to include metadata (optimization)

that's not an optimization, it's something that will result in broken forms when JS is unavailable

does not allow transforming FormData -> POJO with metadata handling on the server

I have no idea what 'with metadata handling' means

adds memory and runtime overhead on the client when the issues and inputs properties are not used

we're talking about microseconds. this simply does not matter

[x0k]

Alright, I tried... Thanks for the answers.

[x0k]

I decided to add a few clarifications — I think it won’t hurt:

I have no idea what 'with metadata handling' means

In my case, it means the form is built from a JSON Schema and parsed according to that schema. I have my own naming and encoding convention to deal with the quirks of both formats (JSON Schema and FormData).

Conversion is necessary because JSON validators have no semantics for transforming input parameters.

Why is the FormData -(SvelteKit)-> POJO -(userland)-> POJO conversion approach not suitable?

• A strict field-naming convention (which is sufficient for me)
• Adding extra conversion quirks on the SvelteKit side doesn’t improve the situation
• Runtime overhead

that's not an optimization, it's something that will result in broken forms when JS is unavailable

However, this guarantees forms will still work with JS when components encode their state incorrectly into FormData. I believe not all forms are required to support working without JS, but the current approach imposes an artificial restriction on how this trade-off can be solved.

we're talking about microseconds. this simply does not matter

Still, it can be addressed by my proposal.

you can transform the object in the callback however you like

• An error is thrown before the callback is even called if the names don’t follow the convention
• Even if you change them, the original FormData is still what gets submitted

[samstorment]

I noticed the docs were recently update to include the new form schema validation. This is awesome!

Is there any word on the manual validation side of things and the proposed invalid function? Or maybe a different suggested pattern for handling issues that can only be discovered outside regular schema validation?

For example, my setup below feels a bit awkward. I'm manually returning a few issues that don't naturally fit into schema validation and it feels clunky for my component to use signup.issues for my schema level problems and signup.result?.issues for my manually returned problems.

export const signup = form(signupSchema, async ({ email, username, password }) => {

    const signupEnabled = await signupEnabled();

    // manual form level issue not specific to any one field
    if (!signupEnabled) {
        return {
            issues: { $form: 'Signup is disabled' }
        }
    }

    const existingProfile = await getUserProfileByUsername(username);
     
    // manual issue specific to the username field
    if (existingProfile) {
        return {
            issues: { username: 'Username is taken' }
        };
    }
    //...
})

[Rich-Harris]

Would something like this work?

export const signup = form(signupSchema, async ({ email, username, password }, invalid) => {

    const signupEnabled = await signupEnabled();

    // manual form level issue not specific to any one field
    if (!signupEnabled) {
-       return {
-           issues: { $form: 'Signup is disabled' }
-       }
+      invalid([{ message: 'Signup is disabled' }]);
    }

    const existingProfile = await getUserProfileByUsername(username);
     
    // manual issue specific to the username field
    if (existingProfile) {
-       return {
-           issues: { username: 'Username is taken' }
-       };
+      invalid([{ name: 'username', message: 'Username is taken' }]);
    }
    //...
})

And if the issues come from a standard schema library:

const result = Schema.safeParse(data);

if (!result.success) {
  invalid(result.error.issues);
}

In other words:

declare function invalid(issues: StandardSchemaV1.Issue[] | Array<{ message: string, name?: string }>): never;

[AndreasHald]

This api would satisfy all the requirements we would have of invalid

[samstorment]

Would this continue to expose the issues for each field as object properties on signup.issues? I'm curious how it would look to render root level issues compared to field level issues. Here's what I'm imagining:

<script>
    import { signup } from "../auth.remote";
</script>

<h1>Sign Up</h1>

<!-- Using $form to stand-in for root level issues. This could be named anything -->
{#if signup.issues?.$form}
    <ul>
        {#each signup.issues.$form as issue}
            <p class="issue">{issue}</p>
        {/each}
    </ul>
{/if}

<form {...signup}>

    <label for="username">Username</label>
    <input type="text" name="username" id="username"/>
    {#if signup.issues?.username}
        <ul>
            {#each signup.issues.username as issue}
                <p class="issue">{issue}</p>
            {/each}
        </ul>
    {/if}

    <label for="password">Password</label>
    <input name="password" type="password" id="password"/>
    {#if signup.issues?.password}
        <ul>
            {#each signup.issues.password as issue}
                <p class="issue">{issue}</p>
            {/each}
        </ul>
    {/if}

    <button type="submit">
        Sign Up
    </button>
</form>

[Rich-Harris]

It's issues.$ rather than issues.$form, and it's a rollup of all issues. If you want only the issues that aren't associated with a specific field you'd need to do something like this:

<script>
    import { signup } from "../auth.remote";

    const issues = $derived(signup.issues.$?.filter((issue) => !issue.name));
</script>

<h1>Sign Up</h1>

<!-- Using $form to stand-in for root level issues. This could be named anything -->
{#if issues}
    <ul>
        {#each issues as issue}
            <p class="issue">{issue}</p>
        {/each}
    </ul>
{/if}

[fredviken]

What is the recommended way to handle prefilled values? Setting the value prop on an input element doesn't seem to populate the myForm.input object; it only gets filled when you change the input value (which I assume is the expected behaviour). And setting the values directly via the myForm.input e.g. myForm.input = { name: user.name} only seems to work client-side.

So e.g. this would display the input value but not the 'Current value:'

<form {...myForm}>
<input value={user.name} name="name" />

Current value: {myForm.input.name}

I guess a current workaround would be to use the initial data as fallback value: {myForm.input.name ?? user.name)

[Rich-Harris]

Fallback, or you can just mutate myForm.input on initialisation.

I did wonder about populating input when the attachment runs, but that would cause an SSR/CSR discrepancy

[jdgamble555]

In case any one is not aware, there is a different thread talking about how the current implementation of form will only allow schemas to have a string and file type (which is what formdata is). Otherwise, you have to coerce your schema, basically making your schemas overly complex and unusable as is.

While I am definitely pro normal schemas, it opens up great questions I think should be considered on the right way to handle it.

#14459 (comment)

In my mind there is no point in having a schema that cannot work out of the box, so it should work as expected, or be removed completely from the form function.

Svelte is its own language, and I prefer anything features that save me time. Handling form data is something any complex component needs to simplify without the same boilerplate over and over.

J

[jdgamble555]

I get it, it seems like that would solve the problem by having the default value, but I will need to test it to make sure it can cover the basic use cases. It is arguably more accurate, so it make sense. Just saying what others do.

I still like the idea of allowing the data to be modified first before validating the schema. This would be the most flexible and IMHO should be added anyway.

I'm assuming superforms just looks at the schema to see what is an array, file, boolean, number or date respectively and handles them based on that.

[GauBen]

What API could possibly solve this problem with less of a compromise than v.optional(v.boolean(), false)?

Well, fg.checkbox(), that's the whole point of the library, it offers a better DX than all other JSON/JS validation libraries because it acknowledges that FormData/form <input>s are weird.

The same goes for this hideous v.pipe(v.string(), v.transform((s) => Number(s)), v.number()) in the documentation, it shows that Standard Schemas are not designed to handle FormData objects. fg.number() does just that: get a numeric string and return a number.

I'm a bit skeptical by this <input {...signup.fields.preferences.contact.email.as('checkbox')} />, but SvelteKit has pushed several weird patterns in the past that revealed to be absolute DX delights, so I'm still trusting the team.

[Rich-Harris]

The ideal, in my mind, would be something that was as FormData-aware as Formgator (i.e. it exposed things like checkbox()), but still worked with POJOs. It's useful to be able to nest stuff (which requires opinionated name handling — opinions which are better expressed in SvelteKit than in a validation library), and it would be annoying to have to use (and learn) two validation libraries so that you can use both form and query/command/prerender.

I wish every validation library included something like v.checkbox() but it's probably too niche (since it basically only makes sense in this exact circumstance, where you've converted form data to a POJO).

I'm a bit skeptical by this <input {...signup.fields.preferences.contact.email.as('checkbox')} />

I hear you! It does indeed look pretty weird. But it solves a bunch of problems at once

• it allows us to treat preferences.contact.email as a boolean (at least in the case that it's checked...)

• it's much nicer than flattened keys, and you get a vastly better autocomplete/typechecking experience than with this:

  <input
    type="checkbox"
    name="preferences.contact.email"
    checked={signup.input['preferences.contact.email']}
    aria-invalid={!!signup.issues['preferences.contact.email']}
  />

• it means that value/checked and aria-invalid actually get populated. these are super easy to forget, but generally won't cause anything to fail obviously, which means that the average app is less accessible and progressive-enhancement-friendly than if we do that by default

[GauBen]

I'm all in for the {...attributes} instead of having to manually set name, type and other properties!

I've been thinking about this in the past but never completed the design: since formgator is aware of HTML-compatible validation attributes (min, required, pattern...), my endgame is to almost automatically create form elements out of the schema

// Define a schema
const schema = fg.form({
  foo: fg.email({ required: true, minlength: 20, pattern: /^.+@gmail\.com$/v })
})

// Retrieve field attributes
schema.field('foo') == {
  name: 'foo',
  type: 'email',
  required: true,
  minlength: 20,
  pattern: '.+@gmail\.com'
}

// Spread them onto an `<input>`
<input {...schema.field('foo')} />

And with reportValidity, client- and server-side validation are virtually identical for the end user

While the setCustomValidity has many design issues, it may be nice to support it out of the box

Edit: the last updates of SvelteKit have me considering creating a formgator/standard export, that exposes standard schema-compatible validators, what do you think?

[Rich-Harris]

We had similar thoughts! We ultimately decided against trying to drive validation attributes from the schema because a) default browser validation UI sucks and b) we want a schema that can be used in the client to be an optional extra rather than a hard requirement.

But yeah, supporting standard schema validators in formgator would be cool (I actually thought it already did expose ~standard? Perhaps I've misunderstood). The ideal is definitely being able to use a single validation library across form and command/query/prerender.

[AndreasHald]

Have you considered exporting the function that does FormData -> POJO since FormData and UrlSearchParams are somewhat the same. You could imagine having filters as a GET form using the same naming conventions to filter a query?

<!-- +page.svelte -->

<script lang="ts">
   import { turnFormDataIntoPojo } from 'svelte'
   import { queryData } from '...remote.ts'
   let filters = $derived(turnFormDataIntoPojo(page.url.searchParams))
   let data = $derived(queryData(filters))
</script>

<form>

   <input type="checkbox" name="topic[]" value="Foo" >
   <input type="checkbox" name="topic[]" value="Bar" >
   <input type="checkbox" name="topic[]" value="Baz" >

   <button type="submit">Filter</button>
</form>

[Rich-Harris]

Yeah this is an intriguing idea. I almost wonder if it should be automatic. Something like this:

// src/routes/search/[category]/+page.ts
import * as v from 'valibot';

export const queryValidator = v.object({
  q: v.string(),
  sort: v.optional(v.picklist(['asc', 'desc']), 'asc')
});

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

  // automatically typed, as `params` is today
  params.category; // string
  query.q; // string;
  query.sort; // 'asc' | 'desc'
</script>

Not something to add immediately (too many plates in the air already!) but definitely something to think about.

[saturnonearth]

Sorry to ask, was not sure if this was answered, but will there be a way to use client-side validation without importing from a remote function? Seems like a shame to have built-in client validation from a framework and only tie it to Remote Functions.

[emmnull]

What would you need the framework to provide you for client side validation? Would you want something handing you spreadable attributes (aria-, name, etc.), validation messages and such? Else, if you plan on doing client side only forms, it should be fairly straightforward to just bind your form inputs' values to some object and then just validate it in an onsubmit handler as you would any other object using your validation library of choice.

[Rich-Harris]

What would that look like, exactly? You can do this today, which bit ought to look different?

<form
  method="POST"
  action="/some-action"
  onsubmit={(e) => {
    const data = new FormData();
    const pojo = Object.fromEntries(data); // or something more sophisticated

    const result = MySchema.safeParse(pojo);

    if (result.success) {
      actually_submit(data);
    } else {
      report_issues(result.issues);
    }
  }}
>

[saturnonearth]

What would that look like, exactly? You can do this today, which bit ought to look different?

<form
  method="POST"
  action="/some-action"
  onsubmit={(e) => {
    const data = new FormData();
    const pojo = Object.fromEntries(data); // or something more sophisticated

    const result = MySchema.safeParse(pojo);

    if (result.success) {
      actually_submit(data);
    } else {
      report_issues(result.issues);
    }
  }}
>

I guess I liked the spreadable syntax currently for remote functions, much like https://github.com/fabian-hiller/formisch/tree/main/frameworks/svelte.

For me personally, I will not always be using remote functions, but still would love the option to keep the same clean syntax for handling validation errors and such. I basically just want a super minimal client-side validation, like Formisch, that I can progressively enhance if I want to make something a remote function.

Perhaps this would be outside the scope of the framework, but at the same time, it feels like it's already so close.

[jdgamble555]

What Rich is talking about is the usual boilerplate that other frameworks use:

function submit(event: SubmitEvent) {
    const target = event.target as HTMLFormElement;
    const form = new FormData(target);
    const data = Object.fromEntries(form);
    ...

Maybe this boilerplate could be extracted out, and we could find a way to attach the schema to a rune so that you could easily run set() or valid() functions on it (similar to new Angular signal forms, but schema independent)...

[florianlouvet]

Form validation as greatly simplified some boileplate in the tests I wrote a couple of weeks ago to test remote functions. Great addition. So first, thank you for adding this.
Is there a workaround while we wait for the invalid api to pass non-schema-related issues? (like username already used, ...)

[florianlouvet]

For anyone looking for a temporary solution that would yield minimum change if the invalid API is confirmed as it was described above:

export function mergeObjects<T extends Record<string, any[]>>(o1: T, o2: T): T {
	const result: Record<string, any[]> = {};

	for (const key of new Set([...Object.keys(o1), ...Object.keys(o2)])) {
		result[key] = [...(o1[key] ?? []), ...(o2[key] ?? [])];
	}

	return result as T;
}

type Entry = { name: string; message: string };
function groupByName(entries: Entry[]): Record<string, { message: string }[]> {
	return entries.reduce<Record<string, { message: string }[]>>((acc, { name, message }) => {
		if (!acc[name]) {
			acc[name] = [];
		}
		acc[name].push({ message });
		return acc;
	}, {});
}

export const invalid = (issues: Entry[]) => {
	return {
		success: false,
		issues: groupByName(issues)
	};
};

export const myForm = form(schema, async ({ email, _password }) => {
	const user = await getUserFromEmail(email);
	if (user === null) {
		return invalid([{ name: 'email', message: 'Account does not exist' }]);
	}
        ...
}

<script lang="ts">
	import { mergeObjects } from '$lib/invalid_form';
	import { login } from './form.remote';

	const issues = $derived(mergeObjects(login.issues ?? {}, login.result?.issues ?? {}));
</script>

<form  {...login}>
    <h1>Login to your account</h1>
   ...
  <Input
        aria-invalid={!!issues?.email}
        type="email"
        id="form-login.email"
        name={login.field('email')}
        value={login.input?.email}
        placeholder="m@example.com"
  />
  {#if issues?.email}
        {#each issues.email as issue}
	        <p class="error">{issue.message}</p>
        {/each}
  {/if}
</div>

I'm open to other suggestions if there is another way to do this in the meantime.

[gordysc]

It'd be great if something like this was baked into sveltekit so developers could clearly see how to add errors to issues

[Asguho]

Hi all! I’m trying to use Drizzle ORM and Valibot together with SvelteKit’s new form validation API. Ideally, I’d love to do something like this:

// schema.ts
import { integer, pgTable, text } from 'drizzle-orm/pg-core';
import { createInsertSchema } from 'drizzle-valibot';

export const blogTable = pgTable('blog', {
	id: integer().generatedAlwaysAsIdentity().primaryKey(),
	title: text('title').notNull(),
	content: text('content').notNull(),
});

export const blogInsertSchema = createInsertSchema(blogTable, {});

// auth.remote.ts
import { form } from "$app/server";
import { db } from "$lib/server/db";
import { blogTable, blogInsertSchema } from "$lib/server/db/schema";
import { unstable_coerceFormValue as coerceFormValue } from '@conform-to/valibot';

export const createBlogPost = form(
	coerceFormValue(blogInsertSchema),
	async (data) => {
        await db.insert(blogTable).values(data);
	}
);

This doesn’t currently work out of the box, but I really like the semantics and would love to avoid duplicating validation logic. Is there any way to achieve something similar, or any recommended approach for integrating Drizzle/Valibot schemas with SvelteKit forms? Any advice or pointers would be greatly appreciated!

[jycouet]

This doesn’t currently work out of the box

I think that it would be helpful to know more about what's not working.
It's not only Drizzle ORM and Valibot, I see also @conform-to.

[florianlouvet]

@jycouet I think @Asguho refers to the fact that the form remote function schema inputs must all be of type string or File where as the Valibotschema infered with createInsertSchema from the Drizzle ORMschema will expect other types (such as a number for the idfield). So the automaticaly generated Valibotschema can't be used directly into a form without coercion of the input into the expected types.

[Asguho]

Should have been more specific. @conform-to/valibot adds an extra preprocessing step to strip empty values and coerce form values to the expected type (e.g. v.boolean() will coerce the string "on" from a checkbox input to true).

Here’s what I’m trying to do:

// schema.ts
import { boolean, integer, pgTable, text } from 'drizzle-orm/pg-core';
import { createInsertSchema } from 'drizzle-valibot';

export const blogTable = pgTable('blog', {
	id: integer().generatedAlwaysAsIdentity().primaryKey(),
	title: text('title').notNull(),
	content: text('content').notNull(),
	isPublic: boolean('is_public').notNull(),
});

export const blogInsertSchema = createInsertSchema(blogTable, {});

<!-- signup/+page.svelte -->
<script lang="ts">
  import { createBlogPost } from '../auth.remote';
</script>

<form {...createBlogPost} class="flex flex-col gap-4">
    <input name="title" placeholder="Title" required />
    <textarea name="content" placeholder="Content" required></textarea>
    <input type="checkbox" name="isPublic">
    <button type="submit">Create Post</button>
</form>

// auth.remote.ts
import { form } from "$app/server";
import { blogInsertSchema } from "$lib/server/db/schema";
import { unstable_coerceFormValue as coerceFormValue } from '@conform-to/valibot';

export const createBlogPost = form(
	coerceFormValue(blogInsertSchema),
	async (data) => {
        console.log("Creating blog post with data:", data);
	}
);

When I submit the form, I get the expected output:

Creating blog post with data: { title: 'asd', content: 'asdad', isPublic: true }

But the types don’t work out of the box, and I get this error:

Error: No overload matches this call.
  Overload 1 of 3, '(validate: "unchecked", fn: (data: RemoteFormInput) => unknown): RemoteForm<RemoteFormInput, unknown>', gave the following error.
    Argument of type 'GenericSchema' is not assignable to parameter of type '"unchecked"'.
  Overload 2 of 3, '(validate: StandardSchemaV1<RemoteFormInput, Record<string, any>>, fn: (data: Record<string, any>) => unknown): RemoteForm<RemoteFormInput, unknown>', gave the following error.
    Argument of type 'GenericSchema' is not assignable to parameter of type 'StandardSchemaV1<RemoteFormInput, Record<string, any>>'.
      The types returned by '"~standard".validate(...)' are incompatible between these types.
        Type 'StandardResult<unknown> | Promise<StandardResult<unknown>>' is not assignable to type 'Result<Record<string, any>> | Promise<Result<Record<string, any>>>'.
          Type 'StandardSuccessResult<unknown>' is not assignable to type 'Result<Record<string, any>> | Promise<Result<Record<string, any>>>'.
            Type 'StandardSuccessResult<unknown>' is not assignable to type 'SuccessResult<Record<string, any>> | Promise<Result<Record<string, any>>>'.
              Type 'StandardSuccessResult<unknown>' is not assignable to type 'SuccessResult<Record<string, any>>'.
                Types of property 'value' are incompatible.
                  Type 'unknown' is not assignable to type 'Record<string, any>'.
export const createBlogPost = form(
        coerceFormValue(blogInsertSchema),
        async (data) => {

Is there any way to make this pattern work more seamlessly, or any recommended workaround to automatically coerce schemas?

Thanks again for all the help and for the awesome work on SvelteKit!

[jdgamble555]

The problem is you're introducing a third variable. Does this work without coerceFormValue and just string variables?

@Rich-Harris is adding the ability to boolean and number as he says above, just not complex types.

But agreed, there is no point in having a schema if it is only File and string inputs allowed.

J

[shamokit]

If anyone knows how to create Remote functions that can accept arguments like the following, please let me know 🙏
I'm getting the error all exports from this file must be remote functions. Does this mean I have no choice but to create a schema that takes no arguments?

// chatForm.remote.ts
const getSchema = (min: number) => v.object({
	text: v.pipe(
		v.string(),
		v.minLength(min)
	)
})
export const chatForm = (min: number) => form(getSchema(min), async (data) => {
	// …
});

<form {...chatForm(3)}>
	<button type="submit">Submit</button>
</form>

[phi-bre]

As the error implies, the exported chatForm must be the actual returned value of form(). You are exporting a normal function, which cannot be converted into a remote function call (remote functions are not "real" functions, they are compiled to fetch calls).

But conceptually, even if this were supported by sveltekit, what you're doing would allow the client to arbitrarily set the length that will be validated on the server, IMO negating the benefit of validation entirely...

If you just need a few static length validated functions, you could just export those instead:

const chatForm = (min: number) => form(getSchema(min), async (data) => {
	// …
});

export const chatForm3 = chatForm(3);

[shamokit]

I see, thank you for the explanation.
Since “min” is a value managed in the database and not fixed, it would’ve been nice to handle all the validation within the schema, but I’ll go with validating separately — preflight on the client side and again on the server side.
Thanks again!

[jhechtf]

I created a util for mapping FormData to (mildly?) complex objects -- i'll admit that some of the code is not great quality, but should serve as a reference point. https://github.com/jhechtf/mono/blob/main/packages/arktype-utils/src/formData.ts#L166

I bring it up because recently I tried to use the new form validation available, and even though my forms previously worked with actions, I was running into issues when trying to use the form remote function.

[agillispie]

Quick question about using invalid

Is there a way to just populate the issues fields without creating an error? Currently invalid produces an error which is caught inside of a try catch. This can be problematic if you have some function that has multiple points of failure that may not always be related to form validation.

Lets say I have some login function

// pseudo-ish code thats simplified to hopefully provide context of what i am talking about

const loginSchema = z.object({
    email: z.string(),
    password: z.string()
})

const login = form(loginSchema, async (data, invalid) => {

try {

  const user = await db.user.findUnique({where:{email: data.email}})

  if(!user) invalid(invalid.email("No account found!"))

  const passwordMatch = compare(user.hashedPassword, data.password)

  if(!passwordsMatch) invalid(invalid.password("invalid password!"))

  someMaybeFailFn()

  redirect(303, "/account")

  } catch (e){
// if i called invalid in the try block it is now caught here


// some check here to see if (and why) invalid was called and redo it ( what i want to avoid having to do )

checkIfIsBecauseOfInvalidAndRethrow(e)

// would have to do these checks anyways even if invalid was not used in the try block so no harm no foul

  if (e instanceOf PrismaKnownRequestError) { invalid("Prisma error <message>)}
    else if (e instanceOf someOtherErrorType) {invalid("some other error happened!")}
    else { invalid("Internal server error!")} // dunno why the error happened so just throw a 500

})

Fully admit this may be a skill issue however I am just hoping to avoid having all of my invalid calls being caught and then having to be rechecked in the catch block if possible

[agillispie]

I think what @agillispie touch on the issue I created this morning here: #14677 The problem is with the misinterpreted type of account, which can still be undefined. (If I understand your example correctly).

@florianlouvet My issue isn't a svelte issue, its just how JS/TS works with scoping. However yeah if TS knew that invalid was going to throw then it should know that it would never reach the code in the first place if account didnt exist.

[Rich-Harris]

However yeah if TS knew that invalid was going to throw

yep, it does — invalid returns never (same as error and redirect) which is TS for 'this will always throw'. Means you can do things like this and it works as you'd hope, even if getUser() can return Promise<null>:

const user = await getUser() ?? error(401);

[agillispie]

so i dunno if i was really sleepy last night or what, but this works as expected and I could have probably not even opened this thread.

I will say that if I dont return invalid, then typescript thinks that invalid was never called thus it thinks that no error was thrown as mentioned in the issue raised by @florianlouvet . Both work as expected, just in the above example typescript is happy, in the below example typescript is angry.

[florianlouvet]

Well, after all this time, I just learned that this is how TypeScript might work around Narrowing and Control Flow Analysis when calling a function that returns never. To be sure TypeScript picks it correctly you must either return the function called that returns never(as you did @agillispie) or put the rest of your code in the else close of your condition. Surprised I only fall on this now.

[agillispie]

Well, after all this time, I just learned that this is how TypeScript might work around Narrowing and Control Flow Analysis when calling a function that returns never. To be sure TypeScript picks it correctly you must either return the function called that returns never(as you did @agillispie) or put the rest of your code in the else close of your condition. Surprised I only fall on this now.

i think we both learned something new today lol, I also never had this problem until now. Appreciate the discussion, cheers!

[jbarnat]

Hi everyone,

Building on the conversation around live, client-side validation for remote functions, I did a deep dive into the current form.validate() implementation to understand its behavior around network requests.

TL;DR: form.validate() successfully prevents network requests when validation fails, but makes a server validation request on every keystroke that produces valid data. This makes it unsuitable for live validation UX patterns.

The User Experience Gap

Here's what happens today when typing into a form with form.validate() called on oninput:

1. User types: "Hi" → ❌ Client validation fails (too short) → ✅ No network request
2. User types: "Hi there!" → ✅ Client validation passes → 🌐 Fetch to server with sveltekit:validate_only=true
3. User types: "Hi there! How" → ✅ Still valid → 🌐 Another fetch
4. User types: "Hi there! How are" → ✅ Still valid → 🌐 Another fetch
5. ...and so on for every keystroke

This creates unnecessary server load and doesn't match the expected behavior for live validation, where the goal is to give instant feedback without server round-trips once the client schema is satisfied.

Why This Happens

I traced this to the implementation logic in the source code:

client/remote-functions/form.svelte.js#L588

const validated = await preflight_schema?.['~standard'].validate(convert(form_data));

if (validated?.issues) {
    // Branch taken when validation FAILS
    array = validated.issues;
} else {
    // Branch taken when validation SUCCEEDS
    // because the `issues` property is undefined
    form_data.set('sveltekit:validate_only', 'true');
    const response = await fetch(/* ... */);
}

The logic pivots on the presence of validated?.issues. When validation succeeds, the Standard Schema returns an object without an issues property, triggering the else branch and a fetch request.

Proof with Valibot:

import * as v from 'valibot';

const commentSchema = v.object({
    content: v.pipe(v.string(), v.minLength(10))
});

const fakeFormData = new FormData();
fakeFormData.append('content', 'This is a valid string');
const data = Object.fromEntries(fakeFormData.entries());

console.log(commentSchema['~standard'].validate(data));
// Logs:
// {
//   "value": { "content": "This is a valid string" },
//   "typed": true
// }
// Note: No `issues` property exists on successful validation

This confirms that every valid state triggers a network request, even when we only want client-side validation feedback.

I understand the design rationale: preflight validation is meant to preflight actual submissions, catching errors before they hit the server. The server validation call with validate_only=true ensures client/server schemas stay in sync.

This is perfect for pre-submission validation (validating once before submit), but it doesn't serve the live validation use case (validating on every keystroke without server calls).

The Feature Request

What's needed is a way to tell preflight() to operate in a pure client-side validation mode, separate from submission logic. Perhaps a separate method:

<form {...commentForm.clientValidation(commentSchema)}>

Behavior:

✅ Client validation runs on every keystroke
✅ `form.fields.allIssues()` updates in real-time
✅ No network requests until user clicks submit
✅ On submit, full server validation runs as normal

Current Workaround (Not Recommended)

For reference, here's the hacky solution I'm using now:

<script>
import { commentForm } from './commentForm.remote.js';
import * as v from 'valibot';
	
const BLOCKED = 'blocked';
const OPEN = 'open';

const commentSchema = v.object({
    blockState: v.literal(OPEN), // Prevents auto-submit
    content: v.pipe(v.string(), v.minLength(10))
});

let blockState = $state(BLOCKED);

async function unlockAndSubmit() {
    blockState = OPEN;
    document.getElementById('commentForm')?.requestSubmit();
    setTimeout(() => { blockState = BLOCKED; }, 200);
}
</script>

<form id="commentForm" {...commentForm.preflight(commentSchema)}
  oninput={() => commentForm.validate()}
>
    <input name="blockState" value={blockState} type="hidden" />
    <textarea name="content" rows="4"></textarea>
    <button onclick={unlockAndSubmit}>Save</button>
</form>

{#each (commentForm.fields.allIssues() ?? [])
    .filter(issue => !issue.message.includes(`Expected "${OPEN}"`)) as issue}
    <div>{issue.message}</div>
{/each}

This works but requires hidden fields, timing hacks, and message filtering.

Summary

The current form.validate() implementation is excellent for pre-submission preflight checks, but it sends server requests on every valid state, making it unsuitable for live validation during typing.

To support live validation properly, we need an explicit API that:

• Runs client-side validation on every keystroke
• Prevents network requests until explicit submission
• Maintains type safety and progressive enhancement

Hope this analysis helps!

[jbarnat]

I've found a significantly better approach that avoids the hacky hidden fields and timing tricks. The key insight is to run validation manually outside of the form's validation lifecycle:
svelte

<script>
	import { commentForm } from './commentForm.remote.js';
	import { commentSchema } from './schema.js';

	let formElement;
	let liveIssues = $state({});

	function processValidationIssues(issues) {
		const errors = {};
		if (!issues) {
			return errors;
		}

		for (const issue of issues) {
			const fieldName = issue.path?.[0]?.key;
			if (fieldName) {
				errors[String(fieldName)] = issue.message;
			}
		}

		return errors;
	}

	function handleInput() {
		if (!formElement) return;

		const formData = new FormData(formElement);
		const data = Object.fromEntries(formData.entries());
		const validationResult = commentSchema['~standard'].validate(data);
		liveIssues = processValidationIssues(validationResult.issues);
	}
</script>

<form bind:this={formElement} {...commentForm.preflight(commentSchema)}
 oninput={handleInput}>
	<textarea name="content" rows="4"></textarea>
	<button type="submit">Save</button>
</form>

{#each Object.entries(liveIssues) as [field, issue]}
	<div>{field} :: {issue}</div>
{/each}

By directly invoking the Standard Schema's validate method in handleInput, we get live client-side validation without triggering the form's preflight logic - which means no network requests until actual submission. This keeps the validation truly client-side while still benefiting from the full server-side validation on submit.

Reusable Form.svelte https://gist.github.com/jbarnat/fc29f0eb4d35055534cf348afd61dc71

[jbarnat]

After successfully implementing manual client-side validation, I immediately ran into the next logical challenge: the interaction between live client-side errors and post-submission server-side errors.

After some experimentation, I've landed on a state management logic that feels very intuitive from a user's perspective. I wanted to share it here as it highlights a crucial aspect that any official API for this feature would need to address.

My Proposed Model: "Stale Server Error Invalidation"

Core Principle: Treat a server error as stale the moment a user starts editing the corresponding field. The goal is to ensure the user is never seeing conflicting error feedback.

State Flow Definition

1. Initial State: All fields are considered Clean.
2. User Interaction (Pre-Submission):
   • Typing in a field marks it as Dirty.
   • Live client-side validation provides immediate feedback for this field
3. On Form Submission:
   • All fields are programmatically reset to Clean.
   • The form is submitted.
   • If the server returns errors, they are displayed on all relevant fields (since all are Clean).
4. User Starts Correcting Errors:
   • When the user starts typing in a field that currently displays a server error, that field becomes Dirty.
   • The moment it's Dirty, its server error is immediately hidden.
   • Only the live client-side validation is shown for that field.
   • Other fields that remain Clean continue to display their original server errors until they, too, are edited.

Hope this is helpful for the design process