Hey @crutchcorn, mind assigning me this for me to work on? 🙏

Done! Thanks for taking this on @CheRayLiu.

Something worth considering is how we will/should handle TypeScript typings for transformations.

Unassigned myself for now as I don't see myself working on it any time soon

No worries @CheRayLiu! Thanks for being willing in the first place :)

Just an idea for this feature.
I am currently working on my own form library based around signals. The way I solved this transformation issue, is not by transforming the values onSubmit, but by handling the transformation on a per Field and onChange basis.

In my case, every field can have a transformToBinding function which takes the form value and transforms it for a specific input element (e.g. a number to a string) and a transformFromBinding function which does the opposite (e.g. transform a string to a number)
There is also a special handleChangeBound function (transforms the value before setting it in the form) and transformedValue attribute (the form value just run through the transformer function) that both make use of these transformers.

The benefit of this is, that the typing would be a lot easier, since the FormValues would stay the same and only a per Field type has to change (also that type could then be inferred from the transformer functions).
The second benefit is, that the form always holds the "correct" data at every point in time.

Maybe that might be something worth considering implementing here as well.

Hey @crutchcorn is this issue still up to date? If so, I think I can try to implement a small part of it.

IMO further discussion should go into whether or not transforms on the base schema should be respected. This is how I personally would like it to work:

When we define a zod schema as the validator, the form should allow default values which align with z.input
Then the submit handler should infer the types coming from z.output. This allows us to keep the transformation and base logic in one area rather than defining a base schema that then needs to be merged with the value you pass to something like transformOnSubmit.

See my code stackblitz: https://stackblitz.com/edit/tanstack-form-zvsfcpvd?file=src%2Findex.tsx

I think the idea with z.input and z.output would be great. I've come here by a little googling and colinhacks/zod#1206

There is a proposed solution which uses transform as you suggest @juanvilladev 👍 See colinhacks/zod#1206 (comment)

Looking at standard-schema there is InferInput and InferOutput which would likely be the right approach for tanstack-form I believe.

My use case:

const defaultValues = {
	name: "",
	related_entry_id: null, // <-- this breaks, it's not a number
	// Current workaround: casting as number
	// related_entry_id: null as unknown as number,
};

const schema = z.object({
	name: z.string().min(3),
	related_entry_id: z.number(), // or whatever kind of id you are using, not nullable though
});

const form = useForm({
	defaultValues, // this should use InferInput
	validators: {
		onBlur: schema,
		onSubmitAsync: ({ value }) => {
			// _ideally_ this would also be InferOutput as by tanstack-form semantics it passed sync validation of the schema already. But that would be the cherry on top. 
			try {
				const response = await saveToDb(value);
				return;
			} catch (err) {
				return err.message;
			}
		}
	},
	onSubmit: ({ value }) => {
		// This should use InferOutput
		toast.success(`You created ${value.name} with related id ${value.related_entry_id}`);
	}
});

Unfortunately I fear my TypeScript foo is not good enough to contribute this right now.

Do more people have this issue?

@leomelzer More people definitely have this issue. This is exactly the type of behaviour that I am looking for.

I think the idea with z.input and z.output would be great. I've come here by a little googling and colinhacks/zod#1206

There is a proposed solution which uses transform as you suggest @juanvilladev 👍 See colinhacks/zod#1206 (comment)

Looking at standard-schema there is InferInput and InferOutput which would likely be the right approach for tanstack-form I believe.

My use case:

const defaultValues = {
name: "",
related_entry_id: null, // <-- this breaks, it's not a number
// Current workaround: casting as number
// related_entry_id: null as unknown as number,
};

const schema = z.object({
name: z.string().min(3),
related_entry_id: z.number(), // or whatever kind of id you are using, not nullable though
});

const form = useForm({
defaultValues, // this should use InferInput
validators: {
onBlur: schema,
onSubmitAsync: ({ value }) => {
// ideally this would also be InferOutput as by tanstack-form semantics it passed sync validation of the schema already. But that would be the cherry on top.
try {
const response = await saveToDb(value);
return;
} catch (err) {
return err.message;
}
}
},
onSubmit: ({ value }) => {
// This should use InferOutput
toast.success(You created ${value.name} with related id ${value.related_entry_id});
}
});
Unfortunately I fear my TypeScript foo is not good enough to contribute this right now.

Do more people have this issue?

I have discovered an alternative approach, but I am uncertain whether it is an effective strategy.

const schema = z.object({
	name: z.string().min(3),
	related_entry_id: z.number(), // or whatever kind of id you are using, not nullable though
});

type Inputs = z.infer<typeof schema>;

const form = useAppForm({
    validators: { onChange: schema },
    onSubmit: async ({ value }: { value: Inputs }) => {
         console.log(value.related_entry_id) // number
    }
});

If you assign a type to a value, you do not need to define default values.

are there any solutions by any chance? I would go as far as adding the ability to add additional values from validators functions to the onSubmit of useForm.

This is why I went with io-ts over zod when using react-hook-form. Another common example I would run into is array to a CSV string or mapping an object to and from a string field (e.g. split an IP and Prefix into two fields). io-ts can describe both the serialization/encode and deserialization/decode in a type safe way but its a little clunky.

Why is it clunky?
I use valibot which I think works great with transformations tho haven't used valibot transformations with tanstack form so far 🤓

Why is it clunky? I use valibot which I think works great with transformations tho haven't used valibot transformations with tanstack form so far 🤓

I think for complex types it is quite nice and the functional style composition is also nice. But for simple types, e.g. a string with some length, writing type codecs is a bit more complex than something like zod where you can just chain a type together. Personally I am willing to deal with the verbosity of io-ts because I find the encoding/decoding aspect to be a killer feature