Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zod 4

zod.dev

Post reply on HN
Print view View original

11–20 of 260 posts

Re: Zod 4

#11

Post by worldsayshi »

koolba wrote: post #9
causal wrote: post #5

Zod is a lot better than some of the alternative solutions I've seen. That said, the need for this sort of explicit validation always felt like a failure of where modern web development has taken us. It's so frustrating how full-stack development requires so many ways of describing the same shapes: JS input validation, Swagger for API definition, server-side input validation, ORM for schema conformance, and TypeScrip…

But that’s the whole point of something like this. You do it once and dynamically generate everything else downstream. So change it once in the zod schema and it propagates with type checking through your entire app. The zod schema becomes the source of truth.

Does zod really support that? What if the code base start out with a go backend and a TS/JS component is only added later? It would be nice if the source of truth was a bit more language agnostic.

Re: Zod 4

#12

Post by CharlieDigital »

neilpa wrote: post #4

We're currently evaluating both Zod and ArkType as a replacement for earlier JSON schema validations. The thing I can't get over with Zod is the syntax is _so_ different from defining TS types. Are there reasons to go with Zod over ArkType?

You might like Typia better.

I recently put together a deck for this after some investigation: https://docs.google.com/presentation/d/1fToIKvR7dyvQS1AAtp4Y...

Re: Zod 4

#13

Post by esafak »

koolba wrote: post #9
causal wrote: post #5

Zod is a lot better than some of the alternative solutions I've seen. That said, the need for this sort of explicit validation always felt like a failure of where modern web development has taken us. It's so frustrating how full-stack development requires so many ways of describing the same shapes: JS input validation, Swagger for API definition, server-side input validation, ORM for schema conformance, and TypeScrip…

But that’s the whole point of something like this. You do it once and dynamically generate everything else downstream. So change it once in the zod schema and it propagates with type checking through your entire app. The zod schema becomes the source of truth.

Does it? I don't use Zod on my JVM backend. How would I?

In addition to using OpenAPI, I generate TS interfaces from my data classes in a Gradle task.

Re: Zod 4

#14

Post by esafak »

devin wrote: post #7

Seeing an announcement for a new version of some typescript library I've never heard of shoot to the top of the front page makes me feel extremely out of touch with mainstream dev.

What do you use for validation in TS? Anyone who deals with data should be validating/parsing it.

Re: Zod 4

#16

Post by lyu07282 »

eknkc wrote: post #6
cluckindan wrote: post #3

Between GraphQL and Zod, there really is no comparison. The latter feels clunky and superfluous by design when the former ecosystem can smoothly provide static TS typings without extra work or schema duplication.

Also, I think teflon pans are much better than squids.

Squid ink is black so are teflon pans, the latter feels clunky and superfluous by design when the former type of fruit can smoothly provide vitamins to vertically integrate with our stack.

Re: Zod 4

#17

Post by fkyoureadthedoc »

neilpa wrote: post #4

We're currently evaluating both Zod and ArkType as a replacement for earlier JSON schema validations. The thing I can't get over with Zod is the syntax is _so_ different from defining TS types. Are there reasons to go with Zod over ArkType?

On the ArkType website they talk about speed and DX, but no mention of bundle size. I assume, and maybe this is an unfair assumption, that's because it's bad. I haven't come across ArkType until just now, but I was just checking out Valibot today because it's got a small bundle size.

Re: Zod 4

#18

Post by satvikpendem »

causal wrote: post #5

Zod is a lot better than some of the alternative solutions I've seen. That said, the need for this sort of explicit validation always felt like a failure of where modern web development has taken us. It's so frustrating how full-stack development requires so many ways of describing the same shapes: JS input validation, Swagger for API definition, server-side input validation, ORM for schema conformance, and TypeScrip…

How else would you do it? You could use something like trpc for full end to end type safety but that requires using TypeScript on both the frontend and backend (which not everyone does) and also locking yourself into only the web platform (so no mobile, etc).

Re: Zod 4

#19

Post by crab_galaxy »

worldsayshi wrote: post #10
causal wrote: post #5

Zod is a lot better than some of the alternative solutions I've seen. That said, the need for this sort of explicit validation always felt like a failure of where modern web development has taken us. It's so frustrating how full-stack development requires so many ways of describing the same shapes: JS input validation, Swagger for API definition, server-side input validation, ORM for schema conformance, and TypeScrip…

Yes there should at least be a way to consolidate so that we can agree on format to treat as the source of truth that we can generate the other formats from.

OpenAPI TypeScript is the closest thing I’ve found to perfection when your API is written in a different language than your client.

https://openapi-ts.dev/

Re: Zod 4

#20

Post by johnfn »

I'm curious if anyone here can answer a question I've wondered about for a long time. I've heard Zod might be in the right ballpark, but from reading the documentation, I'm not sure how I would go about it.

Say I have a type returned by the server that might have more sophisticated types than the server API can represent. For instance, api/:postid/author returns a User, but it could either be a normal User or an anonymous User, in which case fields like `username`, `location`, etc come back null. So in this case I might want to use a discriminated union to represent my User object. And other objects coming back from other endpoints might also need some type alterations done to them as well. For instance, a User might sometimes have Post[] on them, and if the Post is from a moderator, it might have special attributes, etc - another discriminated union.

In the past, I've written functions like normalizeUser() and normalizePost() to solve this, but this quickly becomes really messy. Since different endpoints return different subsets of the User/Post model, I would end up writing like 5 different versions of normalizePost for each endpoint, which seems like a mess.

How do people solve this problem?

Post reply on HN