←back to thread

Parse, don't validate (2019)

(lexi-lambda.github.io)
398 points declanhaigh | 1 comments | | HN request time: 0s | source
Show context
bruce343434 ◴[] No.35053912[source]
Note that this basically requires your language to have ergonomic support for sum types, immutable "data classes", pattern matching.

The point is to parse the input into a structure which always upholds the predicates you care about so you don't end up continuously defensively programming in ifs and asserts.

replies(12): >>35054046 #>>35054070 #>>35054386 #>>35054514 #>>35054901 #>>35054993 #>>35055124 #>>35055230 #>>35056047 #>>35057866 #>>35058185 #>>35059271 #
Thaxll ◴[] No.35054901[source]
You're describing deserialization in a strong typing language, sometimes it's not enough, ok your email went to an empty string which is useless.
replies(2): >>35054943 #>>35055012 #
nicky0 ◴[] No.35055012[source]
With Zod: const info = z.object({ name: z.string().min(1), email: z.string().email() }
replies(1): >>35058737 #
ssalbdivad ◴[] No.35058737[source]
Have you seen ArkType (https://github.com/arktypeio/arktype)? Similar parse-based approach to validation with a significantly more concise definition syntax:

const info = type({ name: "string>0", email: "email" })

replies(1): >>35154724 #
1. nicky0 ◴[] No.35154724[source]
No, but I'm a heavy Zod user so ArkType it looks interesting. Thanks for the tip!

Are there any compelling reasons to switch apart from the difference in syntax?