feat: allow to run preflight validation only

[dummdidumm]

That way you can e.g. run preflight on each keystroke and full validation only on blur

---

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

[changeset-bot]

🦋 Changeset detected

Latest commit: 7368c91

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-kit-14744-svelte.vercel.app/

[Rich-Harris]

maybe this, so it's explicitly linked to .preflight(...)?

Suggested change

	clientOnly?: boolean;
	preflightOnly?: boolean;

[sillvva]

What would this look like in practice?

<script>
import { form } from "$lib/remote/forms.remote.ts";
import { schema } from "$lib/schema";

function validate() {
  form.preflight(schema).validate({ preflightOnly: true }); // runs preflight schema
  form.validate(); // runs server schema
}
</script>

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

or

<script>
import { form } from "$lib/remote/forms.remote.ts";
import { schema } from "$lib/schema";

function validate() {
  form.validate(); // runs preflight schema
  form.validate({ preflightOnly: false }); // skips preflight, runs server schema
}
</script>

<form {...form.preflight(schema)}></form>

[Rich-Harris]

The preflight schema would always be used. This just allows you to skip server validation. So you could for example do preflight validation on every keystroke, but additionally run server validation on change events (which are emitted when you blur an input you've been typing into, etc):

<form
  {...myform.preflight(schema)}
  oninput={() => myform.validate({ preflightOnly: true })}
  onchange={() => myform.validate()}
>...</form>

[Rich-Harris]

One thing I don't love about this is that server issues get nuked as soon as preflight-only validation succeeds. We can fix that with a simple change...

-const is_server_validation = !validated?.issues;
+const is_server_validation = !validated?.issues && !preflightOnly;

...but then we have another problem: preflight validation issues will be added to server validation issues, instead of replacing them, and it looks really weird.

Fixing that is slightly trickier. I've opened #14759 to address it.

[dummdidumm]

I don't sure I understand - I do want to have the server validation issues persisted when a preflight validation fails. Why wouldn't I? There's no world in which a server validation can be duplicate to a preflight validation, because then the server validation wouldn't have ran in the first place. Having a server validation issue ripped out under my fingers while typing is never a good thing IMO. And IIRC we agreed that we don't want to have them go away, so the simple fix should be enough?

[Rich-Harris]

Consider a case similar to the one in the test case I added in #14759 — on the server you have this schema...

v.object({
	a: v.pipe(v.string(), v.minLength(3, 'a is too short'), v.maxLength(7, 'a is too long')),
	b: v.pipe(v.string(), v.minLength(3, 'b is too short')),
	c: v.pipe(v.string(), v.minLength(3, 'c is too short'))
})

...and on the client you have this:

v.object({
	a: v.pipe(v.string(), v.maxLength(7, 'a is too long')),
	b: v.string(),
	c: v.string()
})

This is contrived, but totally valid — the preflight constraints are a subset of the server-side constraints. If you submit this with empty inputs, preflight validation will succeed and you'll be left with the following:

a is too short
b is too short
c is too short

Currently on this branch, as soon as you start typing into the a input, all those issues get nuked. With the simple change, they don't get nuked, but as soon as I violate the preflight constraint, I end up in this absurd situation:

a is too short
b is too short
c is too short
a is too long

a cannot possibly be both too short and too long. Granted this is a contrived situation, and in many cases could be resolved by making the preflight constraints match the server-side constraints more closely, but to me it indicates that we do need to get rid of server issues if we have newer preflight issues.