Get confident with Zod's schema-validation vocabulary — parsing, safe parsing, refinements, transforms, and type inference.
0 / 5 completed
1 / 5
During a PR review, a teammate uses schema.parse(data) in an API route. A senior engineer suggests safeParse instead. The difference is:
parse() throws a ZodError on failure. safeParse() catches errors internally and returns { success: false, error } or { success: true, data }, enabling error handling without try/catch.
2 / 5
In a code review, a teammate adds .refine() to a Zod schema. In a standup, a junior asks what .refine() does. The correct answer is:
.refine(val => boolean, message) adds a custom validator. It runs after Zod's built-in checks; returning false (or throwing) marks the field as invalid with the provided message.
3 / 5
A PR adds .transform() to convert a date string to a Date object inside a Zod schema. A reviewer asks how .transform() affects the inferred TypeScript type. The answer is:
.transform(val => new Date(val)) changes the schema's output type to Date while the input type stays string. Zod models this with separate Input and Output generic params.
4 / 5
In a design review, the team needs a Zod schema that validates a field's value depends on another field (e.g., endDate must be after startDate). The correct Zod approach is:
Cross-field validation requires z.object({...}).refine(data => data.endDate > data.startDate, ...). The object-level refine receives the full parsed object, enabling comparisons across fields.
5 / 5
During a code review, a schema uses z.infer<typeof schema>. A junior developer asks what this TypeScript utility does. The correct answer is:
z.infer<typeof mySchema> is a TypeScript utility type that extracts the output type of a Zod schema. It eliminates the need to maintain a separate interface alongside the schema.