Feature Request: Auto-infer initialInput defaults from Schema (Single Source of Truth)

[Mado13]

If we are trying to implement the schema as the single source of truth, and we are building the form in the Valibot schema, why are we breaking the contract by initializing the form with undefined as default values?

If my schema states name: v.optional(v.string()) — then yes, initialInput for name should be undefined.

But if my schema states name: v.string() — then the initialInput should be "".

Currently, this forces the developer to manually create an initialInput object, which is just copying their schema into a JavaScript object.

I think inferring the initialInput object from the schema will improve DX and push towards a true single source of truth.

I can work on a PR but I just want to know if there is a compelling reason why Formisch chose to go that way?

[fabian-hiller]

Hey 👋 thank you for creating this PR. I like your idea, but first, I would like to investigate the real-world problems you are facing with the current solution. What benefit do you see in initializing a string schema as an empty string instead of undefined?

[sandros94]

Not OP but jumping in as I do think the tooling I'm after would be of similar use.

Like many I share the validation schemas both for client and server side (Vue and Nitro, in my case) writing them for the latter first. This means that all my schemas and forms live into two different places and require manual syncing and is particularly required because in Vue an input requires its own v-model which its initial state might be different from the empty dirty state, for this we have to use v-model Modifiers.

Small deviation onto Vue's handling of v-model

Before going into valibot and formisch I would like to set a base knowledge (for those who do not know it yet) on v-model Modifiers. Here's a small Vue playground example, but essentially:

1. we have three separate input with three separate states (refs), all accepting a string but different modifiers

• Standard: which initializes as undefined, probably the vast majority of general use-cases
• Optional: which initializes as undefined as well
• Nullable: same as optional but null

2. Make them dirty by insert any string.
3. Then delete the inserted string and we are left with:

• Standard: becomes an empty string ""
• Optional: correctly falls back to undefined
• Nullable: same as Optional but falls back to null

What this means is that in a framework like Vue we always need to define explicitly both initialization and empty behaviour.

Actual example with formisch

Moving onto a generic use of formisch in Vue (you can follow this other vue playground example) we can see that:

1. we have a single name property in the schema which is an optional string that must not be empty
2. if we submit the form as is we see the related log in the console (same as inserting any string)
3. but if we do insert any string an later decide to delete it (not resetting the form, as we might have other information already filled in) the internal Vue state will now become a empty string "" instead of undefined, causing the validation to error out on submit

I've been studying this exact use case for almost a year now and look for a better DX while not requiring a complex API that developers need to learn, but without much success.

One partial workaround for this, that I've started using recently, is to create a custom metadata action that stores the form's information, then writing a composable that extract such information from schema's metadata and do a bunch of v-for and v-bind to directly populate the form and fields. But while I'm unsatisfied with it, this allowed me to only make sure the schema definition is correctly written once and reduce the number of missalignments from collegues and friends that might have forgotten to keep the schema and form in sync.

[Mado13]

Thanks for jumping in @sandros94 — that Vue/Nitro context is interesting.

@fabian-hiller, re: your question about initializing with empty strings — I'm hitting similar friction, just in a client-side Svelte 5 PWA.

The main win I see is type consistency, especially for blur validation.
My setup: I'm following standard mobile UX (Baymard, NNG) which says validate on blur.

// schema expects a string (API requirement)
export const AuthOtpSendSchema = v.object({
  phoneNumber: v.pipe(v.string(), v.nonEmpty("Phone number is required")),
});

// form validates on blur
const form = createForm({
  schema: AuthOtpSendSchema,
  validate: 'blur',
  // no initialInput
});

The problem: if someone taps the input then blurs without typing, form state is still undefined. Valibot throws Invalid type: Expected string but received undefined — technically correct, but useless as user feedback.

So I end up doing this:

const form = createForm({
  schema: AuthOtpSendSchema,
  initialInput: { phoneNumber: '' },
  validate: 'blur',
});

For small forms, fine. For complex ones, that's 15-20 lines of manual defaults.

If v.string() could infer "" automatically, the schema becomes the single source of truth. No wondering 6 months later why only some fields got manual init. And it matches DOM reality — empty input is "", not undefined.

[fabian-hiller]

Thank you for your feedback.

You can also write:

export const AuthOtpSendSchema = v.object({
  phoneNumber: v.pipe(
    v.string("Phone number is required"),
    v.nonEmpty("Phone number is required")
  ),
});

But I know that this can be annoying for large schemas. Another option is to use our message method:

export const AuthOtpSendSchema = v.object({
 phoneNumber: v.message(
   v.pipe(v.string(), v.nonEmpty()),
   'Phone number is required'
 ),
});

However, I can see why it would make sense to initialize it automatically as a string. I glade about your feedback and happy to investigate possible implementations once we know where to go.

@dosu what do you think about it? Think very hard!

[dosubot]

Formisch currently requires you to provide initialInput explicitly—there’s no built-in auto-inference for required fields like v.string() (they start as undefined unless you set them) [docs]. For optional or nullish wrappers, Formisch uses valibot.getDefault(schema) if initialInput is undefined, but not for required primitives [source]. This matches browser defaults but can lead to type errors or poor UX in frameworks like Vue and Svelte, where empty fields are usually "" [docs].

Auto-inference would improve DX and type consistency, especially for large forms and for frameworks where the DOM reality is "", not undefined. However, implementing this is non-trivial: you’d need to traverse the schema, define heuristics for each type (e.g., "" for string, 0 for number, [] for array), and handle ambiguous cases like unions or custom types [source]. There are also edge cases for deeply nested objects, arrays, and variants, which would require careful design to avoid breaking type safety or introducing surprises [source].

A possible path forward could be an opt-in flag or utility that auto-generates initialInput from the schema, with user-overridable defaults and warnings for ambiguous cases. This would let the schema remain the single source of truth, reduce boilerplate, and match real-world form behavior, while still giving developers control when needed.

In summary: auto-inference is desirable and aligns with the single source of truth ideal, but it needs to be designed carefully to handle complex schemas and avoid breaking existing expectations. An opt-in or utility-based approach could offer the best of both worlds.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[sandros94]

[...] For optional or nullish wrappers, Formisch uses valibot.getDefault(schema) if initialInput is undefined, but not for required primitives [source]. This matches browser defaults but can lead to type errors or poor UX in frameworks like Vue and Svelte, where empty fields are usually "" [docs].

Auto-inference would improve DX and type consistency, especially for large forms and for frameworks where the DOM reality is "", not undefined. However, implementing this is non-trivial: you’d need to traverse the schema, define heuristics for each type (e.g., "" for string, 0 for number, [] for array), and handle ambiguous cases like unions or custom types [source]. There are also edge cases for deeply nested objects, arrays, and variants, which would require careful design to avoid breaking type safety or introducing surprises [source].

Indeed these have been my main slowdowns even when developing external custom solution for a number of reasons:

• missing dedicated methods in valibot itself like: getPrimitive to return the base primitive (unwrapping internally if necessary, or should it not?); getList to return the available list of a pickList (required when building selects); and a couple others that I cannot remember atm
• lack of difference between form initialization and the user equivalent of per-field reset (the topic about a user manually deleted a string that had previously written instead of resetting the form entirely, since they might want to preserve other fields which do not want to re-input with a full reset).
• schema traverse for both arrays and objects: I can already see the performance cost for deeply nested schemas, but I'm starting to think this should be expected. This should be achievable with a utility that has a similar api to formisch's path, that returns only the internal information of a partiuclar field within the schema from which we can extract the information required for the above points (primitive, list, variant key, and so on)

Then in my particular use-case it would be useful in formisch to have a way to define or control the props of a field from the schema itself, but this might be workaroundable via a custom metadata and the valibot tooling I've mentioned.

These are just some of my opinion, not saying that they are correct or required. I'm just writing them out to build a discussion upon them and elaborating further this topic