How to determine if a field has actually been validated? (isDirty/isValid not sufficient with debounce)

[fermentfan]

Problem
I'm trying to show a validation success icon (✓) next to fields that have been validated successfully. The challenge is distinguishing between "validation passed" and "validation hasn't run yet."
With debounced async validation, isValid is true by default because there are no errors, not because validation actually passed. Combined with isDirty or isTouched, this still doesn't tell me whether the debounced validator has actually executed.

What I tried

• isValid: true by default, doesn't mean validated
• isDirty: only tracks value changes, not validation execution
• isTouched: only tracks user interaction, not validation execution
• isValidating: tells me validation is in progress, but not that it completed
• Checking errorMap keys: unclear if this reliably indicates validation ran

Desired behavior
Something like a hasBeenValidated or isValidated flag that:

• Is false initially
• Becomes true once any validator has actually executed for this field
• Resets to false when the input value changes (before the debounced validation runs again)
• Allows me to write: showCheckmark = field.state.meta.hasBeenValidated && field.state.meta.isValid

Questions

• Is there an existing way to achieve this that I'm missing?
• If not, would this be a reasonable feature request?
• Is anyone else solving this differently?

Thanks!

[aymenhmaidiwastaken]

You're not missing anything — there's no hasBeenValidated in field meta, and the states you're trying to tell apart really are identical. On form-core 1.33.2, a field that has never validated and one that just passed:

[1] never touched   isValid=true  isValidating=false  errorMap={}  errorSourceMap={}
[5] settled, PASSED isValid=true  isValidating=false  errorMap={}  errorSourceMap={}

Nothing to key off. Your reading of each flag was right.

Worth saving you the detour on the last one you listed, though, because it looks like it works and doesn't. errorSourceMap does pick up a key once a validator has been involved:

[1] never touched          errorSourceMap.keys=[]
[3] settled - FAILED       errorSourceMap.keys=["onChange"]
[5] settled - PASSED       errorSourceMap.keys=["onChange"]     <- survives the pass

which reads like a "this validator has run" marker. But the key is written when a validator produces an error, not when it runs. A field whose validator passes on the first attempt never gets one:

sync validator, passes immediately
  fresh:             errorSourceMap.keys=[]
  after passing run: errorSourceMap.keys=[]

So it's really "has ever errored", and it would silently fail for exactly the fields you want the tick on — the ones that were correct first time. (errorMap is worse for this: it picks up an onMount key straight away, before anything has run.)

What does work is recording it yourself, using listeners to clear and the validator to set:

const field = useField({
  name: 'email',
  listeners: {
    onChange: () => setHasValidated(false),
  },
  validators: {
    onChangeAsyncDebounceMs: 500,
    onChangeAsync: async ({ value }) => {
      const error = await checkEmail(value)
      setHasValidated(true)
      return error
    },
  },
})

const showCheckmark = hasValidated && field.state.meta.isValid

listeners.onChange fires on every value change, ahead of the debounce, so the flag drops the instant the user types and comes back only once the validator has actually finished. Traced through your scenario:

[1] initial                  hasValidated=false isValid=true  CHECKMARK=false
[2] typed, debounce pending  hasValidated=false isValid=true  CHECKMARK=false
[3] settled - invalid        hasValidated=true  isValid=false CHECKMARK=false
[4] typed again, pending     hasValidated=false isValid=true  CHECKMARK=false
[5] settled - valid          hasValidated=true  isValid=true  CHECKMARK=true
[6] typed again              hasValidated=false isValid=true  CHECKMARK=false
[7] settled - invalid        hasValidated=true  isValid=false CHECKMARK=false

Which is your spec exactly, including the reset in [6]. The ordering holds because the listener runs before the validator on every change — 3 listener fires, 3 validator runs, strictly alternating.

Two practical notes. Put the flag in a ref or state rather than a module-level variable if you have more than one instance of the field on screen, since it's per-field state. And if you have many fields, it's less repetitive to keep a Record<string, boolean> keyed by fieldApi.name and have a small wrapper add the two hooks, rather than writing them per field.

As a feature request I think it stands up — the flag is derivable but only from inside the validator, which means every validator has to opt in, and a meta.hasBeenValidated maintained by the library would be both cheaper and correct for the first-time-valid case that the errorSourceMap approach misses.