feat: expose field touched state

[LeeWxx]

#14665

Remote form fields expose field.touched() so apps can see whether a field or its children were interacted with, and client/server runtimes surface the existing touched map.

---

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

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 0d9ce67

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

[hrueger]

Just tested it, works great for me! 👍

[hrueger]

Sorry for asking here about the status again - we're desperately waiting for this feature and this pr has been unreviewed for almost 2 weeks now 🤷‍♂️

Is there anything that can be done to help get this reviewed soon(ish)? Thanks in advance!

@LeeWxx do you think, you can request a review from maintainers?

[LeeWxx]

@hrueger I don’t think I have permission to request reviewers either.
Do you happen to know if there’s any other way to get this reviewed?

[hrueger]

Very strange... I usually don't tag random people as I've heard it is considered rude. So hopefully Mr Svelte himself (aka @Rich-Harris) sees this as a friendly request for review? 😃🙏 thanks in advance!

[firatciftci]

I think it would be beneficial to differentiate (and individually support) both touched and dirty state for form fields, where the former checks for any modification from the original state (and remains touched once any modification occurs), and the latter keeps track of difference from original and current form state (where dirty would be false if all form fields are the same as original, even if touched is true).

[hrueger]

Ideally, I'd want to implement the following behavior:

• I have a field, which can be plain, or outlined green or outlined red with a list of issues
• at the beginning, the field is plain / idle
• When the user types and the validation passes, it becomes green
• when the user types more or removes chats so that the field becomes invalid, it should become red and the issue list should display
• or when the user does not input valid content and the field is blurred, then it should become red

Note that when inputting for the first time, it only can become red after it was already green. So that you don't confuse the user with a min length issue for example while he is still typing.

Does that make sense? Hard to express in writing 😁

Would that be possible without manually keeping track of the validation success of each field? Maybe we need a blurredOnce tracker, too? Not sure.

[Antonio-Bennett]

@LeeWxx I think a good place would be the contributors channel in the svelte discord.

[LeeWxx]

@firatciftci @hrueger I started with adding support for the touched state only in this PR to keep the scope small and focused. Once we agree on the purpose and desired behavior in the issue or discussion, I’m thinking of following up with another PR for dirty and related states. Would that make sense to you?

[jdgamble555]

Hey guys, since touched is agreed, any progress on merging this PR?

[teemingc]

We'll be reworking the form remote function to reduce the client bundle size for users not using these features. We'll likely have to wait until that's in place

[Rich-Harris]

Thank you — finally getting round to this PR. I think the big outstanding question here is how we define 'touched'. At the moment a field is touched when the user edits it, or when it is set programmatically, but I don't think that's quite right.

The main reason to care about this is so that sensible things happen on myform.validate(), which by default ignores untouched fields. Reasonable people can and do disagree about exactly when to show validation errors, and so it might be necessary to have more granularity here (with the aforementioned dirty() method, or with more options when you call myform.validate({...})) but I would love to see if we can come up with something that basically works for everyone.

I think the best guide we have here is how browsers apply :user-invalid and :user-valid when HTML form constraints are applied (even though we disregard HTML form constraints in favour of server-side validation with optional preflight validation). Essentially, these pseudo-classes are applied when the user has 'interacted' with a form control, meaning

1. the control was both edited and blurred
2. a submission was attempted

Some libraries would remove the 'edited and' part of 1 — if a field is required and you skip over it, it's obviously something you will need to go back and fix. But I don't think it's that uncommon to tab through a form to orient yourself, and it's a little annoying if that results in a wave of validation warnings. Do people have strong opinions here? I'm not sure what a good way to make it configurable would be, if we deemed that necessary.

Another nuance: I think it's probably reasonable to ignore programmatic changes that occur before the form is mounted. In other words:

<script>
  import { myform } from './stuff.remote';

  // this would _not_ mark `message` as touched
  myform.fields.message.set('initial');
</script>

<!-- but this would -->
<button onclick={() => myform.fields.message.set('updated')}>
  update
</button>

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

Interested to hear people's thoughts and use cases.

[theetrain]

To me, "touched" implies "interacted with"; while "tainted" implies "initial data has changed".

Other ideas for "touched": changed, focused.
Other ideas for "tainted": modified, mutated, edited, dirty (mentioned).

---

But I don't think it's that uncommon to tab through a form to orient yourself, and it's a little annoying if that results in a wave of validation warnings.

From the MDN :user-invalid example, on Chrome, Safari, and Firefox, it seems tabbing in and out of the field won't immediately invoke the :user-invalid selector; it only invokes when a change has been made and the field is blurred.

I think at least we have the right tools to display errors and decide when to display errors without SvelteKit needing to do anything extra other than expose errors on submit (aria-invalid), programmatic preflight, or via pattern, :user-invalid and related attributes and selectors. Exposing tainted certainly helps with displaying or hiding "you have unsaved changes"-type messages.

[jdgamble555]

I'm happy with just touched for now, since it is already tracked internally, but if you want to be conscious of all cases, we can look at what Angular has been doing for almost 10 years since Angular 2:

https://angular.dev/guide/forms/signals/field-state-management#field-state-signals

• touched() - User has focused and blurred the field (if interactive)
• dirty() - User has modified the field (if interactive), even if value matches initial state

J

[Rich-Harris]

We certainly could expose both. The bigger question for me — and I realise this is tangential to the current PR — is what the behaviour of myform.validate() should be. If I'm validating in an oninput or onfocusout handler, should that mark a touched-but-not-dirty <input> with aria-invalid="true" (assuming it is invalid), or not?

Also, should touched() (or indeed dirty()) always become true upon submission? I think yes, because you would want validity to be updated immediately if you were updating a form post-invalid-submission. But you could argue that that's just something that should be tracked internally, i.e. myform.validate() should behave the same as myform.validate({ includeUntouched: true }) when myform.submitted === true (unless the form was reset).

[jdgamble555]

1. (with help from CHAT)

aria-invalid communicates to assistive technologies that the current value is invalid. If a required field starts empty, then:

• User tabs into it.
• User tabs out without typing.

Technically the value is invalid, but announcing it immediately is often a poor experience because the user hasn’t attempted to provide a value yet. Many users are simply navigating the form.

The concepts of touched, dirty, and submitted represent different things and are best kept separate.

• Touched: The user has focused the control and then left it (blurred it).
• Dirty: The user has changed the value.
• Submitted: The user attempted to submit the form.

A form submission doesn’t imply either of the first two happened.

Recommended behavior

On submit:

• ✅ submitted = true
• ❌ Don’t automatically set dirty = true
• ❌ Don’t automatically set touched = true

Just thoughts of AI

J

[Rich-Harris]

Yeah, the maintainers spent some time on this earlier today and basically converged on the same conclusions. Basically instead of myform.validate() excluding fields that weren't touched(), it would exclude those that weren't dirty(). (I suppose we need to rename { includeUntouched: true } to { includeClean: true }.)

I'll do that in a follow-up PR once this one passes CI