Benefits of static types in Zod

[ivan-kleshnin]

I'd like to say first that this library is truly a piece of art in API design.
Many kudos and tons of respect to the author.

I'd like to question, hovewer, the benefit/drawback ratio for TS types derived from validators.

A typical use of Zod schema after the declaration is to pass it to the form hook:

const schema = Z.object(...)

const form = useForm({schema, initialInputs}) // for example...

And that is the end of schema. It does not affect the returned form in any visible way. And so it doesn't matter if ZodSomething is an opaque or an obscure type.

I have an extensive experience with Zod (1,2,3). I use the strictest TS setups in my projects. I've implemented my own Formik-like library which depends on Zod. Given all that, I can't tell a single moment when I relied on Zod types being super-strict and transparent belowuseForm invocation.

Dare one say extreme type-safety may hinder more than help. A typical example:

const companySizes = [{value: "1-10"}, {value: "11-20"}, {value: "21-..."}] // this constant is used in selects

- companySize: Z.enum(companySizes.map(c => c.value)), // can't simply pass an array here
+ companySize: Z.enum(companySizes.map(c => c.value) as any), // @_@

I can't pass values to Z.enum because it expects literal to derive "truly type-safe" tuple.
I can't put a literal there because of DRY. Validators mimic and repeat UI values more often than not...

typeof companySize is never really used anywhere on the client side.
So all that magically complex type machinery serves... no purpose outside of Zod and even obfuscates client code 🤷

To not overestimate my personal experience, I'd like to hear from people who use Zod.
Does your code benefit from calculated/derived static types and how exactly?

[scotttrinh]

For my usage, it's almost entirely the other way around. We define schemas to replace the interfaces we had throughout our server, and occasionally use the validation part in a few specific places.

[ivan-kleshnin]

What's the benefit of using Zod schemas instead of normal TS types?

[scotttrinh]

When you do need to parse something, you don't have to handroll the type guard, or anything else. Practically the same number of lines to write a schema + infer as writing the interface, and you get all of the benefits of the schema when you need it.

[scotttrinh]

In other words, a schema + infer has strictly more capabilities than just the type would at the cost of a single line difference:

interface Person {
  id: string;
  name: string;
}

vs

const personSchema = z.object({
  id: z.string(), // and maybe even some refinement here!
  name: z.string(),
});
type Person = z.infer<typeof personSchema>;

Doesn't seem to be a big deal, but compare that to suddenly needing a type guard or parser:

function isPerson(candidate: unknown): candidate is Person {
  // probably a dozen lines here to get the same level of certainty here
}

function parsePerson(candidate: unknown): Person {
  // probably dozens more if you include stripping unknown keys, adding refinements or transforms, etc.
}

[scotttrinh]

Also, I believe in your example, you could re-write it the other way around to get both safety and ergonomics:

const companySizeSchema = z.enum(["1-10", ...]);
type CompanySize = z.infer<typeof companySizeSchema>;

const companySize: { value: CompanySize }[] = companySizeSchema
  .options
  .map((option: CompanySize) => ({ value: option }));

[ivan-kleshnin]

Thank you for the clarification, Scott! That is definitely interesting and something to ponder upon.

[ivan-kleshnin]

I've had some time to think about the idea of Zod-first types and I think I've found a couple of strong counterarguments.

If you take the proposed approach of defining validators with Zod and getting TS types for free...

1. Bundle Size

You'll have so much more runtime artefacts. If you're developing FE app, its bundle size will substantially increase. TS types are compile-time but validators are run-time. Even if treeshaking successfully removes most of them... people often forget about dev mode where no treeshaking happens. I don't like my dev bundles being 60-80Mib instead of 20-40. It feels sluggish it breaks the flow and decreases my own performance as a developer. Bundle size will be a problem with this approach for FE apps.

2. Dynamic types

Most of the time Zod schemas can be defined in module space and TS type derivation is natural. Some of the time, hovewer, validators depend on dynamic data. It's common when you have async validators with someId in them. You'll have that id only dynamically cause it's part of the routing system (of React, NextJS, whatever) and you'll need to send it to API. For example, when you check duplicate email, you'll need to exclude me.id from the check.

In such cases it's no longer possible to define schema in module space. Which means the approach fails you – TS types aren't first class objects and you can't return them from a function. Parametric types in TS are incompatible with this idea. And in my code all schemas are defined dynamically to have just a single way of defining them.

So while I agree to the idea that sometimes, for some projects the approach of Zod -> TS works and even is the best one I don't think it's universal. In my FE code I will keep using TS -> Zod and hopefully I was clear about reasons for that.

[scotttrinh]

1. Bundle Size

I'm not sure I follow. In what world would you use Zod and not incur the overhead of bundling the runtime validation? Or are you saying that you don't want to define all of your types in Zod? If that's the case, then I agree! Since we're defining our domain model on the server, we don't incur any "bundling cost", but we have plenty of interfaces and types that don't make sense to check at runtime that are not defined in Zod at all. We haven't yet done much client-side validation using Zod, so your FE-first approach probably makes sense. I'm just not sure how defining the types in TS and then defining the schemas saves on bundle size since it would generate the same bundle.

2. Dynamic types

Some of the time, hovewer, validators depend on dynamic data. It's common when you have async validators with someId in them. You'll have that id only dynamically cause it's part of the routing system (of React, NextJS, whatever) and you'll need to send it to API. For example, when you check duplicate email, you'll need to exclude me.id from the check.

Can you give some concrete example in code of what you mean here? I'm not sure I understand your explanation, but I'm sure we've run into similar usages so can offer a perspective on this.

So while I agree to the idea that sometimes, for some projects the approach of Zod -> TS works and even is the best one I don't think it's universal. In my FE code I will keep using TS -> Zod and hopefully I was clear about reasons for that.

I'm glad going from TS to Zod works for you, and I'm sure there are ways to improve the developer experiences for that use case. I'm curious as to what you were hoping to get out of this discussion other than getting some examples of how people use z.infer. Is there some specific change that you're hoping to see?

[ivan-kleshnin]

I'm not sure I follow. In what world would you use Zod and not incur the overhead of bundling the runtime validation? Or are you saying that you don't want to define all of your types in Zod? If that's the case, then I agree!

Yes. The difference between bundling Zod validators for all types vs just forms will be huge.

Can you give some concrete example in code of what you mean here? I'm not sure I understand your explanation, but I'm sure we've run into similar usages so can offer a perspective on this.

The following makeSchema function is necessary to define validators parameterized by account:

let makeSchema = ({account}) => {
  let schema = Z.object({
    username: Z.string().min(3).max(50).refine(s => s.match(/^[-a-z0-9]*$/)),
    fullname: Z.string().min(3).max(50),
    ...
  }).refine(async ({username}) => {
    return !username || isAccountUsernameUnique({id: account.id, username})
  }, {
    message: "This username is already taken",
    path: ["username"],
  })

  return {schema}
}

I'm sure it's not possible to extract types from such schema on the module level where you don't have an account var. So the whole approach Zod -> TS is not applicable. The reverse one, hovewer, will be ok.

I'm glad going from TS to Zod works for you, and I'm sure there are ways to improve the developer experiences for that use case. I'm curious as to what you were hoping to get out of this discussion other than getting some examples of how people use z.infer. Is there some specific change that you're hoping to see?

I'm interested in how other people use Zod. No particular request of something to change in mind.
It's just dawned on me that I never used a huge part of this library (type derivation).

[scotttrinh]

That was super helpful, thanks!

This is so far out of the realm of how we use Zod that I get why we're pretty confused at each other! We use it to have a runtime representation of known and static types that we would write types (and validators/parsers) for manually before, such as Account in your case. I think we would approach the issue like this:

const account = Z.object({
  username: Z.string().min(3).max(50).refine(s => s.match(/^[-a-z0-9]*$/)),
  fullname: Z.string().min(3).max(50),
  // etc
});
type Account = z.infer<typeof account>;

const makeSchema = ({ account }: { account: Account }) => {
  const schema = account.refine(
    async ({username}: Account) =>
      !username || isAccountUsernameUnique({id: account.id, username}),
    {
      message: "This username is already taken",
      path: ["username"],
    }
  );

  return { schema };
}

Whether or not you care about the inferred type of your refined schema is not obvious from your example, but I'm not sure what the problem with this, or even the original code you posted is? Seems perfectly fine to make these dynamic schemas at runtime, and it's unhindered by the fact that static types exist or are possible.

[ivan-kleshnin]

Yeah, interesting... For some reason I didn't think about (re-)refining predefined schemas.
It certainly looks like a powerful pattern. Thank you for sharing the idea 👍

[scotttrinh]

FWIW, since TypeScript uses nominal typing the runtime refinements you get aren't really enforceable without using a branding trick like #210 (comment). But, once you have those enforced brands, you get some nice properties of being able to catch compile-time issues of even dynamically generated schemas as long as you have a strict way of building the branded type. In other words, having the static branded type means you can know at compile-time that if you have a ValidatedAccount it is actually validated with your refinement.