←back to thread

Stop writing CLI validation. Parse it right the first time

(hackers.pub)
203 points dahlia | 7 comments | 06 Sep 25 18:20 UTC | HN request time: 0.092s | source | bottom
Show context
jmull ◴[06 Sep 25 22:14 UTC] No.45153373[source]▶
> Think about it. When you get JSON from an API, you don't just parse it as any and then write a bunch of if-statements. You use something like Zod to parse it directly into the shape you want. Invalid data? The parser rejects it. Done.

Isn’t writing code and using zod the same thing? The difference being who wrote the code.

Of course, you hope zod is robust, tested, supported, extensible, and has docs so you can understand how to express your domain in terms it can help you with. And you hope you don’t have to spend too much time migrating as zod’s api changes.

replies(4): >>45154508 #>>45154791 #>>45155254 #>>45156821 #
bigstrat2003 ◴[07 Sep 25 02:16 UTC] No.45154791[source]▶
Yeah, the "parse, don't validate" advice seems vacuous to me because of this. Someone is doing that validation. I think the advice would perhaps be phrased better as "try to not reimplement popular libraries when you could just use them".
replies(6): >>45154814 #>>45155095 #>>45155795 #>>45156024 #>>45163088 #>>45177851 #
1. dwattttt ◴[07 Sep 25 03:14 UTC] No.45155095[source]▶
Sibling says this with code, but to distil the advice: reflect the result of your validation in the type system.

Then instead of validating a loose type & still using the loose type, you're parsing it from a loose type into a strict type.

The key point is you never need to look at a loose type and think "I don't need to check this is valid, because it was checked before"; the type system tracks that for you.

replies(1): >>45155874 #
2. 8n4vidtmkvmk ◴[07 Sep 25 06:26 UTC] No.45155874[source]▶
Everyone seems hung up on the type system, but I think the validity of the data is the important part. I'd still want to convert strings to ints, trim whitespace, drop extraneous props and all of that jazz even if I was using plain JS without types.

I still wouldn't need to check the inputs again because I know it's already been processed, even if the type system can't help me.

replies(2): >>45156099 #>>45160080 #
3. dwattttt ◴[07 Sep 25 07:20 UTC] No.45156099[source]▶
The type isn't just there to make it easy to understand when you do it, it's for you a year later when you need to make a change further inside a codebase, far from where it's validated. Or for someone else who's never even seen the validation section of code.

I'm hung up on the type system because it's a great way to convey the validity of the data; it follows the data around as it flows through your program.

I don't (yet) Typescript, but jsdoc and linting give me enough type checking for my needs.

replies(2): >>45158166 #>>45193593 #
4. k3vinw ◴[07 Sep 25 13:54 UTC] No.45158166{3}[source]▶
jsdoc types are better than nothing. You could switch to using Typescript today and it will understand them.
5. Lvl999Noob ◴[07 Sep 25 17:15 UTC] No.45160080[source]▶
Pure js without typescript also has "types". Typescript doesn't give you nominal types either. It's only structural. So when you say that you "know it's already been processed", you just have a mental type of "Parsed" vs "Raw". With a type system, it's like you have a partner dedicated to tracking that. But without that, it doesn't mean you aren't doing any parsing or type tracking of your own.
replies(1): >>45193575 #
6. hdjrudni ◴[10 Sep 25 05:12 UTC] No.45193575{3}[source]▶
I don't think that's what people are talking about when they say types. They're talking about TypeScript types, not mental models of object structure.
7. hdjrudni ◴[10 Sep 25 05:14 UTC] No.45193593{3}[source]▶
Don't get me wrong, I love TypeScript types. And if I didn't have TypeScript, I'd use jsdoc.

I'm just saying that TypeScript and jsdoc don't actually do any runtime enforcement. It's important that the library does that part, with or without types.