Add atomic fields validation/re-validation mode

[vasilii-kovalev]

Proposal

Currently, even when setting validate: "change", when the user changes a value in one of the fields, all the fields in the form are validated, and all the related errors are shown.

This ticket is a request to implement the same approach as in React Hook Form with mode: "onChange". In this case, when the user changes a value in one of the fields, an error (if any) is displayed only for that field, and all the fields are validated at once only on submit.

The same goes for revalidate/reValidateMode.

I think it is a balanced UX approach, because the alternatives have problems:

• With validation on submit (default for Formisch), if there are validation issues, users need to go and fix them in the fields they already touched before = double work
• With validation for all the fields on change in one of them (with validate: "change"), users are overwhelmed by all the appeared errors

Performance

The whole schema is validated on each keystroke now anyway when validate: "change" is used (from what I understand), so it is only necessary to update the errors state more atomically. No performance degradation expected.

Additionally I was thinking about if Formisch could run only the relevant checks from the provided schema using

• pick to get the main checks for the related field AND
• Check for the field's name in partialCheck, and if it is there, run such validations as well (not sure if Zod and other libraries could provide the means for that like Valibot does, though) AND
• If there are custom validations that can't provide a clear information, what fields are used inside, run them just in case

[fabian-hiller]

I think we already support this. You can combine .errors with .isTouched. This allows you to only display errors for fields that have been touched.

While an atomic field validation feature is theoretically possible, it is complex in practice and would require us to integrate Valibot much more deeply. This could prevent us from becoming independent of the schema library one day, and also supporting other schema libraries.

[vasilii-kovalev]

Using isTouched and/or isDirty doesn't help.

I've created an example with two versions of the same form built with Formisch and React Hook Form. The approach in Formisch is not 1-to-1 to RHF behavior because it is currently impossible to achieve it.

Check the README.md file. It is written with AI, but I squeezed the truth and factual accuracy from it through multiple loops, so I hope it will provide you with something useful. It contains information about how RHF handles the UX I described and the scenarios in which the libraries differ.

Even with the current implementation, it is clear that it would be necessary to create a separate component/function on the users' side to achieve the UX I described in each project, so I'd argue that it would be better to implement it on the library's side.

[fabian-hiller]

Thank you for taking a closer look at it. I will try to prioritize this within the next 2 or 4 weeks as I agree that this is important. Feel free to take a look at our code and come up with ideas. Your AI should be pretty good in explaining how Formisch is designed and maybe also with ideas on how we could improve this.

@dosu can you take a look at this issue as well as our source code and come up with ideas on how we can improve this?

[dosubot]

Great question! I've dug into the Formisch source code and architecture to understand how validation works today and how atomic per-field error display could be improved. Here are my findings and ideas:

Current Architecture

Today, Formisch always validates the entire schema whenever any field triggers validation [1]. The validateFormInput() function parses the full form input against the Valibot schema, then distributes errors to individual field stores via walkFieldStore() — fields without issues get null, fields with issues get their error tuples [2].

The validateIfRequired() function [3] decides when to validate based on the validate/revalidate modes, but it always runs full-schema validation when triggered.

The Gap

As @vasilii-kovalev correctly identifies, the issue isn't about what gets validated (the full schema runs anyway for correctness), but about which errors get surfaced to the UI. Right now, after validation, all field errors are updated simultaneously in the batch operation [4]. The workaround is field.isTouched to conditionally render errors [5], but this is a display-level concern pushed to userland.

Ideas for Improvement

Idea 1: Built-in errorVisibility mode (minimal change, big UX win)

Add a form-level option that controls when errors become visible on each field, separate from when validation runs:

const form = useForm({
  schema: mySchema,
  validate: 'blur',
  revalidate: 'input',
  errorVisibility: 'touched', // NEW: 'all' | 'touched' | 'dirty' | 'submitted'
});

Implementation: In the error distribution loop inside validateFormInput() [6], instead of always assigning errors, gate the assignment based on the field's state:

walkFieldStore(internalFormStore, (internalFieldStore) => {
  const fieldErrors = nestedErrors?.[internalFieldStore.name] ?? null;
  
  if (errorVisibility === 'all' || shouldShowErrors(internalFieldStore, errorVisibility)) {
    internalFieldStore.errors.value = fieldErrors;
  }
  // Still store "pending" errors internally for when the field becomes visible
});

This would need an internal _pendingErrors signal separate from the public errors signal. When isTouched becomes true, pending errors would flush to errors.

Pros: No schema library coupling, backwards compatible, solves the UX problem at the library level.
Cons: Adds complexity to the validation flow; need to handle the "flush" when field state changes.

Idea 2: Per-field validate/revalidate override

Allow field-level validation mode overrides:

<Field of={form} path={['email']} validate="blur" revalidate="input">
  {(field) => <input {...field.props} />}
</Field>

Implementation: Store per-field validation config in the field store [7]. In validateIfRequired() [8], check the field-specific config before the form-level config. This wouldn't change what validates, but would let individual fields control when their errors appear.

Idea 3: visibleErrors computed property

Add a reactive computed property on each field that factors in the field's interaction state:

get visibleErrors() {
  if (!internalFieldStore.isTouched.value && !internalFormStore.isSubmitted.value) {
    return null;
  }
  return internalFieldStore.errors.value;
}

This is essentially what users are doing manually today [5], but built into the library. It preserves errors as the raw validation state while giving a "smart" property that respects interaction state.

Pros: Zero breaking changes, purely additive, trivial to implement.
Cons: Doesn't solve the underlying architectural limitation — just formalizes the workaround.

Idea 4: Scoped validation via Valibot's pick (future/advanced)

For true per-field validation (e.g., async email uniqueness checks), you could introduce an optional validateField() API:

import { pick } from 'valibot';

// Internal: extract sub-schema for a specific path
const fieldSchema = pick(formSchema, ['email']);
const result = safeParse(fieldSchema, { email: fieldValue });

This would require Valibot-specific knowledge but could be opt-in. The current parse function stored in InternalFormStore [9] could be complemented by a parseField method that uses pick() internally.

Pros: True per-field validation, enables async field checks without validating the full form.
Cons: Couples more tightly to Valibot; doesn't handle partialCheck or cross-field validations; may conflict with the schema-library-agnostic goal.

My Recommendation

I'd suggest Idea 1 + Idea 3 as a combined approach:

1. Add visibleErrors as a quick win (trivial implementation, immediate DX improvement)
2. Add errorVisibility mode for the "atomic display" behavior at the form config level

This keeps full-schema validation intact (preserving correctness and simplicity), avoids Valibot coupling, and solves the UX problem @vasilii-kovalev describes — errors only appear for fields the user has interacted with, while all fields validate on submit.

The key architectural insight is: separate validation execution from error visibility. The schema should always validate fully (for correctness and cross-field dependencies), but the display of errors can be progressive and interaction-aware.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[vasilii-kovalev]

I've created a repository with the example to make it easier for us to refer to the code. I also changed the link in my previous comment from the ZIP archive to the repository.

The README.md file I referred to.

I also asked an AI agent to see if Dosu's proposal is the best we can get or if there is a better one. And it seems there is! The solution.md file describes why Dosu's proposal is suboptimal and a better solution to achieve the intended UX.

[fabian-hiller]

Would adding an isEdited boolean next to isTouched and isDirty solve this issue nicely, or would you prefer that Formisch choose a different approach?

[vasilii-kovalev]

I'd like the library to take care of it so that developers don't need to write the same code for the same common behavior over and over again. RHF has this behavior built-in, which removes the boilerplate. If I understand correctly, your proposal with isEdited aims to make the API as flexible as possible so that users can combine the booleans themselves in the way they need for their use case. Maybe it makes sense to do both - have a default/common behavior implemented (to reduce repetition) and extend the API with the flag (to support advanced/unusual requirements). It's just... I think it may be quite hard to predict all the scenarios, so maybe it makes sense to start from what is known and well-established (like the behavior I described and RHF supports) and then iterate on restrictions (like the library's philosophy) and use cases users come up with. Maybe it makes sense to implement the behaviors other libraries already support to avoid reinventing the wheel and then add to it if necessary.

So basically I'd like the library to implement the behavior. But if the flag should be exported, or if the other behaviors should be aligned with other libraries - it is secondary.

Additionally, I think for the project itself it may be useful to describe the borders of library/API responsibility. It would help with making decisions like this in the future. For example:

• Atomic as possible, and users (or other libraries built on top) build abstractions if necessary (support any use case vs. boilerplate for typical use cases)
• Zero customization/boilerplate by default
• Both zero customization/boilerplate by default AND rich/atomic API for advanced uses cases

[fabian-hiller]

isEdited is merged and available soon. I will try to take another looks at this issues in the next few days. #142

[fabian-hiller]

Quick status + a decision I'd like input on.

The atomic primitive this needs already landed: isEdited is set only on value changes (not focus), stays true after reverting to the initial value, and resets on reset(). So RHF mode: "onChange" parity is exactly isEdited || isSubmitted — show a field's error once it's been edited, and everything after the first submit.

The open question is how much of the display gating the library should own. Three options:

A — Document only. Users apply isEdited || isSubmitted themselves.

• ✅ No new API; the primitive is already there; stays minimal/headless.
• ❌ Same guard re-written in every project; easy to reach for isTouched by mistake and reintroduce the focus bug.

B — Add a visibleErrors field property (returns errors when isEdited || isSubmitted, else null).

• ✅ Library owns the logic; one-prop swap; no breaking change.
• ❌ Two error properties — every user (even those who don't want this) has to learn errors vs visibleErrors. Highest ambient complexity.

C — Opt-in form config that makes field.errors itself progressive (default off).

• ✅ Nothing changes at the call site — you still render field.errors. Matches RHF, where errors is the progressive object. Zero cost/learning for anyone who doesn't enable it. isValid / getErrors / getDeepErrors stay correct (they read the raw state, not the gated getter).
• ❌ One new config flag; need to decide whether getErrors / getDeepErrors / form-root errors also respect it.

I'm leaning A. In practice most people wrap fields in a reusable component (a TextField, FieldError, etc.), so isEdited || isSubmitted gets written once and reused everywhere — the per-field boilerplate concern largely disappears. That keeps the core minimal and isEdited already gives you everything needed to build the exact RHF behavior.

B I'd avoid — a second error property is a concept every user has to carry, even those who don't want progressive display. C stays on the table if we later decide the library should own this out of the box.

What do you think about this? What would you do?

[vasilii-kovalev]

Quick status + a decision I'd like input on.

The atomic primitive this needs already landed: isEdited is set only on value changes (not focus), stays true after reverting to the initial value, and resets on reset(). So RHF mode: "onChange" parity is exactly isEdited || isSubmitted — show a field's error once it's been edited, and everything after the first submit.

The open question is how much of the display gating the library should own. Three options:

A — Document only. Users apply isEdited || isSubmitted themselves.

• ✅ No new API; the primitive is already there; stays minimal/headless.
• ❌ Same guard re-written in every project; easy to reach for isTouched by mistake and reintroduce the focus bug.

B — Add a visibleErrors field property (returns errors when isEdited || isSubmitted, else null).

• ✅ Library owns the logic; one-prop swap; no breaking change.
• ❌ Two error properties — every user (even those who don't want this) has to learn errors vs visibleErrors. Highest ambient complexity.

C — Opt-in form config that makes field.errors itself progressive (default off).

• ✅ Nothing changes at the call site — you still render field.errors. Matches RHF, where errors is the progressive object. Zero cost/learning for anyone who doesn't enable it. isValid / getErrors / getDeepErrors stay correct (they read the raw state, not the gated getter).
• ❌ One new config flag; need to decide whether getErrors / getDeepErrors / form-root errors also respect it.

I'm leaning A. In practice most people wrap fields in a reusable component (a TextField, FieldError, etc.), so isEdited || isSubmitted gets written once and reused everywhere — the per-field boilerplate concern largely disappears. That keeps the core minimal and isEdited already gives you everything needed to build the exact RHF behavior.

B I'd avoid — a second error property is a concept every user has to carry, even those who don't want progressive display. C stays on the table if we later decide the library should own this out of the box.

What do you think about this? What would you do?

I don't understand what the "C" option means. It looks like it behaves like RHF, but the text says it needs additional configuration. Not sure what additional configuration beyond "mode" is necessary. If it is actually just mode: "onChange" just like in RHF and nothing else, then I'm voting for that.

"A" is less preferable. But maybe it could be done better, and isEdited || isSubmitted could be combined in a new flag the library exports?

"B" is the least preferable option because of its ❌.

Also, the optionals talk about "No new API". Probably it makes sense to lean towards the "ideal" approach, because the library is not stable anyway, and breaking changes are expected if they make the library better aligned with the vision.

To sum up, I'd like the behavior out of the box. But if the philosophy of the library is to give all the controls to users, I would accept this.

Did you decide about this?

Additionally, I think for the project itself it may be useful to describe the borders of library/API responsibility

Because without it, it will be hard to make the decision here.