Hacker News new | ask | show | jobs
by dhruvrajvanshi 620 days ago
> Other statically-typed languages do have to deal with the problem of parsing external objects.

Well that's just blatantly not true. Which languages are you thinking of? I'm sure I'm misunderstanding what you said.

I can't think of a single server side language that doesn't have to parse external untyped objects. That's where these serialization libraries come into play.

For example, in Kotlin, you declare a data class and mark it as @Serializable and it generateds `toJSON/fromJSON` for you. IMO it's a much better experience than Zod.
1 comments
yen223 620 days ago
> I can't think of a single server side language that doesn't have to parse external untyped objects.

That's what I said too.

> For example, in Kotlin, you declare a data class and mark it as @Serializable and it generateds `toJSON/fromJSON` for you. IMO it's a much better experience than Zod.

If the JSON object matches the data class exactly, the Zod parser and the Kotlin Serialization parser and Jackson and all those other JSON parsers are similar in complexity.

However, where Zod shines is if the JSON object doesn't match your domain class exactly, e.g. you want to parse a JSON number into a Date, or you want to parse a string field into some custom domain object. In those cases, in zod this is a one-liner with `.transform(...)`. Other libraries will require all kinds of weird workarounds to support this.

The other thing Zod does really well is composition, i.e. making new schemas out of existing schemas. Something like this is difficult to express in most language's parser frameworks:

  const User = z.object({id: z.string(), username: z.string(), ...})
  const CreateUserPayload = User.omit({id: true})  // Same as user, but without the id field
  const UpdateUserPayload = CreateUserPayload.partial()  // Same as CreateUserPayload, but now all the fields are optional
link