How to use separate "input" and "output" types with schema validation resolvers

[Svish]

Take the following schema written using yup:

const yupSchema = yup.object({
  income: yup.number().label('Inntekt').nullable(true).required().integer().min(0),
});
type YupValues = yup.TypeOf<typeof yupSchema>;
// { income: number | null | undefined; }
type YupValid = yup.Asserts<typeof yupSchema>;
// { income: number; }

I now want to use these types with useForm:

const { handleSubmit } = useForm< ??? >({
    defaultValues: {
      income: null
    }
})

return (
  <form
    onSubmit={handleSubmit(data) => {
      console.log({ data })
    })}
  >
    ...
  </form>
)

The issue is that I have to substitute ??? for either YupValues or YupValid. Picking the first allows me to set the default value to null, but gives me the wrong type in my submit-handler. Picking the second gives me the correct data type in my submit-handler, but doesn't allow me to use null as a default value...

Is there a way to do this correctly typewise? I assume the type being passed into the submit-handler will have been through the yup resolver and therefore will be valid and match the YupValid type, so I suppose I could "cast" it with an as YupValid, but I really don't like using as if I can avoid it.

---

There's a similar concept with zod, which is actually called input and output:

const zodSchema = z.object({
  strLength: z.string().transform((val) => val.length)
});
type ZodValues = z.input<typeof zodSchema>;
// { strLength: string }
type ZodValid = z.output<typeof zodSchema>;
// { strLength: number }

Here it would similarly be great if there was a way to get the correct type in the correct places when using react-hook-form.

[iambryanhaney]

+1 here.

ResolverResult is inheriting the TFieldValues given to useForm, but imho if a resolver is present its actual output should be the type of ResolverResult and thus passed to handleSubmit's onValid. Ideally that would look something like:

const schema = z.object({
  amount: z.number().nullable().transform((v) => v ?? 0)
});

type FormFields = z.input<typeof schema>;
// { amount: number | null | undefined }

type FormPayload = z.output<typeof schema>;
// { amount: number }

const form = useForm<FormFields, FormPayload>({
  resolver: zodResolver(schema),
});

const handleSubmit = form.handleSubmit(
  function onValid (payload) {
    // { amount: number }
  }
);

At present, the only resolution I know of (as @Svish suggests) is to hard-assert it in the submit handler....

const handleSubmit = form.handleSubmit(
  function onValid (values) {
    const payload = values as unknown as FormPayload;
    // { amount: number }
  }
);

[bennettdams]

Also just a hack, but maybe helpful for someone.

I took another approach: Instead of allowing null for the default values, I don't allow null in the schema (used by tRPC endpoints), but only overwrite the type of specific fields for the default values of React Hook Form. That way, the API endpoints are 100% safe in their usage.

Here's a small helper to make one or more fields of your schema undefined:

export type OmitStrict<T, K extends keyof T> = T extends unknown
  ? Pick<T, Exclude<keyof T, K>>
  : never

export type Undefinable<T> = T | undefined

/**
 * This is a hack for a schema that needs an `undefined` field on the input which is not allowed to be `undefined` for the output.
 * This situation e.g. exists on fields of an initial form to create something. e.g. we don't want to have a category selected when
 * a new post is created, so the field is `undefined`.
 */
export type FormDefaultValuesUndefinable<
  TSchema extends z.ZodTypeAny['_output'],
  TKeyToOverwrite extends keyof TSchema
> = OmitStrict<TSchema, TKeyToOverwrite> & {
  [K in keyof TSchema as TKeyToOverwrite]: Undefinable<TSchema[TKeyToOverwrite]>
}

In this example I expect a categoryId when creating a post in my API endpoint, but I don't want to provide a default value for it, hence the undefined. Here, only categoryId should be undefinable, the rest of the schema remains unchanged:

type SchemaCreatePost = z.infer<typeof schemaCreatePost>

const defaultValuesCreate: FormDefaultValuesUndefinable<
  SchemaCreatePost,
  'categoryId'
> = { title: '', categoryId: undefined }

[Svish]

Interesting... although, as you say, still quite the hack, I might consider doing something like that actually. Could make authoring schemas and using our <Form> component a bit easier.

Just an FYI if you're not aware though: react-hook-form strongly recommends not using undefined for defaultValues, so you might want to switch to null there instead?

• Important: You should provide a proper default value and avoid undefined.
  • undefined is reserved for fallback from inline defaultValue/defaultChecked to hook level defaultValues.
  • undefined value is conflicting with controlled component as default state

https://react-hook-form.com/api/useform

I've personally had issues with the second note there, about components being rendered first as uncontrolled components (with default set to undefined) and then switching to controlled once I enter a value.

[bennettdams]

I would love to use null here, as it better represents the "there is no value" idea. Using null won't work though - undefined only works because RHF's type allows default values to be optional.
Not sure if there's a better way than this hack - I feel like this is such a common use case?

[tomashaddad]

Funnily enough, I posted #9332 yesterday with a similar problem: null is an allowed form value to represent nothing selected, but it is not an allowed submission value due to schema rules.

I think that we should be allowed to specify different types for form values and submission values (valid and on error). I wonder how Formik (or others) handled this? I didn't use them enough to run into this, unfortunately.

[bryanhaney-shipengine]

I've personally had issues with the second note there, about components being rendered first as uncontrolled components (with default set to undefined) and then switching to controlled once I enter a value.

@Svish There's a note here on a good technique to mitigate this. https://react-hook-form.com/advanced-usage#Transform

Working example for a NumberInput component:

const transform = {
  in: (v: number | null | undefined) => (Number.isNaN(v) ? "" : v ?? ""),
  out: (e: React.ChangeEvent<HTMLInputElement>) => {
    const parsedValue = parseFloat(e.target.value);
    return Number.isNaN(parsedValue) ? null : parsedValue;
  },
};

// in the component
  <Input
    onChange={(e) => field.onChange(transform.out(e)}
    value={transform.in(field.value)}
    ....
  />

So, you're ensuring that the field state always receives a number or null, and the DOM input always gets a number or empty string, even if the field state is null or undefined.

That helps decouple from the impedance mismatches between Zod <-- RHF --> DOM.

[KevinHerklotz]

To answer your original question. You can do this now:

const { handleSubmit } = useForm<InputType, unknown, OutputTypeAfterValidation>({
  // ...
})

[juanvilladev]

If I'm not mistaken, ideally when we pass the schema in, determining the input and output types should be abstracted to the library as it can infer the types using z.input/output?

[silogos]

any update for this?

[BrendanC23]

RHF can infer the input/output types from the schema resolver without needing to provide the generics.