2024-07-16
3166
#typescript
Abhinav Anshul
137956
Jul 16, 2024 ⋅ 11 min read

Schema validation in TypeScript with Zod

Abhinav Anshul Doing interesting things on the Web.

Recent posts:

the replay oct 15 graphic

The Replay (10/15/25): AI’s accessibility problem, React 19.2, and more

Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the October 15th issue.

Matt MacCormack
Oct 15, 2025 ⋅ 34 sec read
AI has an accessibility problem: What devs can do about it

AI has an accessibility problem: What devs can do about it

Jemima Abu examines where AI falls short on accessibility and how we can best harness AI while still building products that everyone can use.

Jemima Abu
Oct 15, 2025 ⋅ 10 min read

Want to run your AI model locally? Here’s what you should know

Cloud AI made scaling easy, but local AI brings control, cost stability, and data privacy. Explore the hardware realities, tradeoffs, and strategies shaping this shift.

Clara Ekekenta
Oct 15, 2025 ⋅ 6 min read

Stop writing REST APIs from scratch in 2025

Writing REST APIs by hand is a thing of the past. Frameworks like tRPC, Fastify, and Hono eliminate boilerplate with schema-driven design, improving speed and safety.

Ikeh Akinyemi
Oct 14, 2025 ⋅ 3 min read
View all posts

3 Replies to "Schema validation in TypeScript with Zod"

  1. Correct me if I am wrong, but you don’t use the parse function with TS typically… you infer the type, effectively from the ZOD ‘model’ (I call it) and then you assign that type to the variable, or function return or whatever as you would usually do with TS. Then parse is done inherently as part of type checking, but standardized with ZOD models.

    Got a huge app, sharing front and backend code, express/vite. Express has routes hierarchical frontend doesn’t, plus has it’s own router. Trying to share route strings mostly and response types. Also trying to figure out naming conventions… ATM I am using SomethingModel for the ZOD stuff and SomethingModelType for the type inferers but its a bit verbose.

  2. I’m searching for good examples of how to name the zod schema objects.
    Unfortunately your examples disappointed me.

    When you ask a programmer what ‘dataInputFromUser’ means they would think it’s a variable that holds the actual data entered by the user at runtime.
    To express the intended meaning ‘dataInputFromUserSchema’ would be more to the point.

    Identifier with upper camel case names (like ‘UserData’) usually denote either a class, interface, enum, global constant or a type. So it’s clear that these variables don’t hold the values itself, but rather describe the allowed/expected value. Hence such a name is not that missleading.
    But typically you also want to have a TS type with the same name (‘UserData’). Unfortunately this w/could lead to a name clash. So ‘UserDataSchema’ seems to be the solution here.

  3. Great Article! One possible error in the article to correct. Under the section Adding a custom validation with Zod:
    .refine((data) => data.mobileNumber === data.confirmMobileNumber
    This should probably be !== in order to trigger the message?

Leave a Reply