Schema review!

[mzalevski]

Hi, I thought that it would be helpful if we could review complicated schemas here. Let me start. Consider the schema below. How could I do better?

Things to think about:

1. Numeric strings validation.
2. Extracting refinement functions, e.g. z.object({ ... }).refine(adminSecretLogic).refine(adminCodeLogic).
3. Overall code quality & best practices.

import * as z from "zod";
import isNumeric from "validator/lib/isNumeric";

interface User {
  id: string;
  isAdmin: boolean;
  adminSecret?: string;
  adminCode?: string;
}

const userSchema: z.ZodSchema<User> = z
  .object({
    id: z.string(),
    isAdmin: z.boolean(),
    adminSecret: z.string().max(20).optional(),
    adminCode: z.string().length(4).optional(),
  })
  .refine(data => (data.isAdmin ? data.adminSecret : true), {
    message: "Admin secret is missing from an admin user.",
    path: ["adminSecret"],
  })
  .refine(
    data =>
      data.adminSecret && data.adminSecret.length > 10
        ? data.adminCode && isNumeric(data.adminCode)
        : true,
    data => ({
      message:
        data.adminCode && !isNumeric(data.adminCode)
          ? "Admin code needs to be digits only."
          : "4-digit admin code is missing from an admin user with a long secret.",
      path: ["adminCode"],
    })
  );

// Admin secret is missing from an admin user.
userSchema.parse({
  id: "20ec0677-68d8-45b5-a522-16cff767ac6f",
  isAdmin: true,
});

// 4-digit admin code is missing from an admin user with a long secret.
userSchema.parse({
  id: "20ec0677-68d8-45b5-a522-16cff767ac6f",
  isAdmin: true,
  adminSecret: "moreThenTenChars",
});

// Admin code needs to be digits only.
userSchema.parse({
  id: "20ec0677-68d8-45b5-a522-16cff767ac6f",
  isAdmin: true,
  adminSecret: "moreThenTenChars",
  adminCode: "a134",
});

// No errors!
userSchema.parse({
  id: "20ec0677-68d8-45b5-a522-16cff767ac6f",
  isAdmin: false,
});

// No errors!
userSchema.parse({
  id: "20ec0677-68d8-45b5-a522-16cff767ac6f",
  isAdmin: true,
  adminSecret: "belowTen",
});

// No errors!
userSchema.parse({
  id: "20ec0677-68d8-45b5-a522-16cff767ac6f",
  isAdmin: true,
  adminSecret: "moreThenTenChars",
  adminCode: "1234",
});

[prescience-data]

It would make the code easier to read with a ```typescript prefix on the code block.

Is there a reason you are manually defining User rather than inferring it?

export const UserSchema = z
  .object({
    id: z.string(),
    isAdmin: z.boolean().default(false),
    adminSecret: z.string().max(20).optional(),
    adminCode: z.string().length(4).optional(),
  })

export type User = z.infer<typeof UserSchema>


const myUser: User = UserSchema.parse({ id: "foo" })

[mzalevski]

I know that you meant the above. I mean it too :)
I know that these are equivalent but:

1. if you infer the User interface, then after you userSchema.parse(obj), the returned object is not recognized as User but as an object literal with all the fields from interface (not as the interface tough!)
2. using const userSchema = ZodSchema<User> = object({ ... }) declaration also ensures a tight 1:1 binding. It won't compile if the userSchema is not compliant with the User interface.

[prescience-data]

Ah, interesting, so this actually doesn't ===? More like a loose ==?

export type User = z.infer<typeof UserSchema>

===

export interface User {
  id: string;
  isAdmin: boolean;
  adminSecret?: string;
  adminCode?: string;
}

[mzalevski]

I would not say it's loose. It is indeed tightly coupled. I think that what I am talking about is simply due to order of operations. The User interface does not yet exist at the moment of defining the schema. Hence the schema has no way to know that you would really like to see User in your IDE intelisense :)

[prescience-data]

Ah, so it's more a preference thing?
I always define my schemas first as concrete, then export the inferred interfaces (and in turn use those throughout the application).
It sounds like the distinction is that you prefer the reverse where the schema is subordinate to an existing interface / type?

[mzalevski]

Correct :)