Feature Request: modeling different resolver input and output types

[jedwards1211]

Is your feature request related to a problem? Please describe.
I'd like to be able to declare a Zod schema that uses transforms like z.object({ interval: z.string().transform(s => parsePostgresInterval(s)) }) to do parsing from raw string input like 1 day 3 hours to a value like { days: 1, hours: 3 }. But that results in different input and output types, and that contradicts the definition of Resolver which uses the same type for input and output field values.

Describe the solution you'd like
Maybe have separate input and output type parameters in Resolver instead of the same input and output type? If I used { days?: number, hours?: number } etc in TFieldValues, it would misrepresent the actual raw value type in the form state (just string).

Describe alternatives you've considered
Tbh I am here because I started writing my own form state manager based upon Zod before I found react-hook-form, and I'm trying to decide whether to go with react-hook-form since it's widely used, or continue down my own path. And I wanted to bring this to your attention in case you think it's worth considering how to support this use case.

The docs seem to officially recommend using a custom <Controller> for this use case, but:

• it would be nice to be able to specify transforms in my Zod schema instead of my React components
• it seems like <Controller> probably doesn't persist the raw value and it can get lost in some cases? I wonder if invalid raw values would get lost in an infinite scroll if the control unmounts?

Having worked with other form libraries before I'm always surprised that none of them seem to store raw values in internal state. I can't see a way to get totally clean behavior without it.

One option would be storing the parsed value in form state if valid, and otherwise the invalid string that failed to parse. But I would also have to store the raw string locally so that the input doesn't suddenly reformat to a normalized value while the user is typing.

Or I could have raw and parsed subtrees of my form schema and some kind of pattern of converting between them. That might be complicated though.

Additional context
In addition to parsing from input to output, I made zod-invertible for a nice way of making schemas that can format from output values back to raw input values.

So far I've designed my form library to accept input or output as initial values or in setters, and it parses or formats from one to the other as necessary. I find this nice because then I can pass fields that come straight out of my API in a parsed format (like { days: 1, hours: 3 }) straight into my form, but have them be editable as text, and then get them back as parsed values in my submit handler.

[danieldecsi]

I just came here to the issues the check if anyone else is having this problem. :D

[danieldecsi]

I just found a PR that could solve this: #11951