Does coerce defeat the purpose of infering a type from a schema?

[ianpaschal]

Background

I'm working on a React project where I have a form with a schema which looks something like:

const matchSchema = z.object({
  player_0_id: z.string().uuid(),
  player_1_id: z.string().uuid(),
  winner: z.number().min(0).max(1),
});

type Match = z.infer<typeof matchSchema> ;

const form = useForm<Match>({
  resolver: zodResolver(matchSchema),
});

Logically, I chose to implement it this way so that if one of the players is changed (or swapped), the winner ID doesn't become out of sync.

However, I'd like to allow the user to select the winner from a dropdown of the two players. Thus logically I'd have something like:

<Select
  options={[
    {
      label: players.find((player) => player.id === formData.player_0_id).name,
      value: 0,
    },
    {
      label: players.find((player) => player.id === formData.player_1_id).name,
      value: 1,
    }
  ]}
/>

...only most Select components I've found (in my case I'm using Radix UI) don't support non-string values because HTML selects don't support non-string values.

So I can solve this by using "0" and "1" as my values, and adapting my schema with coerce: winner: z.coerce.number().min(0).max(1).

But here's the problem...

If I infer the type from my schema, Typescript will say winner is a number, because that's what Zod says it is. But if I try to check typeof winner, it's a string.

Of course, for the sake of using Zod to validate my form inputs, I want it to coerce the string into a number, but when I infer the type from the schema I want it to accurately reflect the fact that winner is a string. This seems to go against the idea that Zod is TS friendly if the type I've inferred from the schema is actually wrong.

Of course, the really ideal situation would be that winner is a number and z.coerce is not needed at all, but that's a question for Radix. It doesn't change the fact that I'm curious, "Why does this method (z.coerce) exist which seems to create wrong typings by design?"

So the big questions are...

• How should coerce be used? Using it to handle form inputs which are the wrong type seems like it will completely destroy the point of using a TypeScript-first form validation method.
• How should one handle these mismatches between what the front-end components what re: data types, and what the back-end expects? winner could be a z.string() since that's what the form input uses, but then I can't use number-specific validation tools like .max() and .min().

[ianpaschal]

A follow up thought:

It feels like a better way to design the coerce functionality would be to provide two values: one for typing and one for validation.

The syntax should look something like:

z.string().coerce(z.number().min(0).max(1)),

Thus you would be explicit about what the value actually is (a string) and what you're validating it as (a number).

Because right now, when used in the manner described above with react-hook-form, which I gather from the Internet is a common practice, the form data will be incorrectly typed.

[BrendanC23]

Can you explain further why you need winner to be a number? If it's just for validating min/max (and the winner can only be 0 or 1 but not an arbitrary decimal value), you can use z.enum(["0", "1"]) instead. This keeps the winner value as a string for your select component while also handling the validation with Zod.

Another option would be to use z.transform and have separate input and output types.

const schema = z.object({
    winner: z.string().transform((value, ctx) => {
        const valueAsNumber = Number(value);

        if (isNaN(valueAsNumber)) {
            ctx.addIssue({
                code: z.ZodIssueCode.custom,
                message: "Winner should be a string representation of a number.",
            });

            return z.NEVER;
        }

        return valueAsNumber;
    }),
});

type InputType = z.input<typeof schema>; // { winner: string }
type OutputType = z.output<typeof schema>; // { winner: number }

If needed, you can do additional min/max checks within the transform.

[ianpaschal]

Because it's stored as a number. So it's:

A. Quite crappy to have to convert it to a string and back to a number when JS is a language with support for number types.
B. Annoying that if I want to compare the form data to back-end data, I'm comparing "0" === 0 instead of 0 === 0.