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

Parse, Don't Validate – In a Language That Doesn't Want You To

cekrem.github.io

Post reply on HN
Print view View original

91–100 of 107 posts

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#91

Post by Lvl999Noob »

Xenoamorphous wrote: post #86
sheept wrote: post #78

Earlier quoted context omitted.

What you're doing is essentially what Zod is designed to avoid. If you tolerate needing a separate build step more than having to define types with Zod's syntax, then it makes sense not to use Zod since it's not made for you.

To me the build step is a good thing. It's a simple script in npm, and it means I only keep what I need (the JSON Schema, which I don't need at dev time) in runtime and whatever package generates those schemas out of TS types can remain as a dev dependency. zod can't be a dev only dependency, and you have to deal with breaking changes and maybe switching to a completely different library in a few years (joi, with a s…

How would you use zod as a dev-only dependency? The whole point there is to be a parser. If you remove it from runtime then you are not parsing the production payloads, which is the exact place where you do need to parse them.

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#92

Post by botfriendsarent »

Xenoamorphous wrote: post #55

I don't like zod. I want to define my types, not write schemas. And I don't like that then I have to use the types derived from those schemas rather than types I've defined myself directly. So I just define my types and then use typescript-json-schema or similar to build a JSON Schema at build time (i.e. from an npm script) which then I use to validate input using ajv. The only thing I do on top of that is to use ann…

This is what I also do not just in JS but also in other languages. But I write the schemas. And I dont use TS. Im glad Im not the only one. The OP post gave me a serious headache trying to read it.

Parse and Validate are not binary choices and have nothing to do with each other. Both are useful when applied correctly to a given situation.

I felt punked by most of it. I dont see what programming languages have to do with it either. Look at swift, a language that can barely only barely parse JSON. Who cares?

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#93

Post by toolslive »

esafak wrote: post #73
toolslive wrote: post #71

You don't have to use TypeScript if you don't want to: you can compile Haskell, Ocaml, Rust, F#, ... to javascript. This is quite efficient, especially if your backend is already in one of those languages. It saves you from creating the same abstraction twice in different languages.

How does that work with JS frameworks like React, since most development takes place with them?

it's not that different compared to using the FFI.

The link below shows how it can work for Ocaml TypeScript.

https://github.com/ocsigen/ts2ocaml

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#95

Post by terminatornet3 »

whilenot-dev wrote: post #84
terminatornet3 wrote: post #72

Earlier quoted context omitted.

The original author is correct. Their implementation of an exhaustive check will give you a compiler error if you miss a variant in your switch statement. I much prefer a compiler error over a run time error. It's even recommended in the official typescript docs - https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...

> Their implementation of an exhaustive check will give you a compiler error if you miss a variant in your switch statement. I much prefer a compiler error over a run time error. What are you talking about? You'd still get the compile error just the same. Falling back on returning the input argument doesn't even make sense in the typescript docs: type Shape = Circle | Square; function getArea(shape: Shape) { switch (…

you don't need a runtime error if you have a compiler error. best of luck with your PR

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#97

Post by cptmurphy »

steve_adams_86 wrote: post #80
programmarchy wrote: post #48

Earlier quoted context omitted.

I haven’t used Effect but the problem I see with using it is that it seems to want to completely swallow the whole app architecture. At that point, why not just use a functional language?

I can’t think of a single functional language that offers what effect gives you, though. A fully typed and declarative error channel, managed dependency layer with compile time safety, excellent resource management, the best parsing/validating/serializing library I’ve used in TypeScript, concurrency, streams, cache, otel primitives baked in… In all fairness it does require buy-in and gradual adoption isn’t perfectly…

Scala. Zio/Cats/Kyo

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#98

Post by SebastianKra »

jerf wrote: post #45
Altern4tiveAcc wrote: post #17

Zod is by far the most ergonomic way to express those ideas in TypeScript these days. I miss it when writing code in other languages. The friction with the rest of the ecosystem is real, though. Most code out there expects you to handle errors with exceptions. I get the impression that polymorphic return types could get in the way of JSC/V8/SpiderMonkey's JIT, but I haven't measured it and I'm not sure of the actual…

I haven't done a lot of Typescript, but I've done at least a couple of month's worth now, and every time I have to type "as" my inner Haskell programmer screams. If I could add one feature to Typescript it would be something like "as" that actually validates the result against the type system and can fail. Unfortunately, that's way, way easier said than done. It's the bad type of keyword that has unbounded runtime co…

I wonder what you're doing that you need to type it so often. I almost never use it in application code (outside of tests and generic utilities).

There are some techniques that aren't immediately obvious. Look into...

- type guards

- pushing constraints up: `function print(i: Invoice & { issueDate: string })` is better than `assert(i.issueDate)`

- discriminated unions

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#99

Post by gabes »

Xenoamorphous wrote: post #55

I don't like zod. I want to define my types, not write schemas. And I don't like that then I have to use the types derived from those schemas rather than types I've defined myself directly. So I just define my types and then use typescript-json-schema or similar to build a JSON Schema at build time (i.e. from an npm script) which then I use to validate input using ajv. The only thing I do on top of that is to use ann…

I think this misses what is undeniably the best part about zod. Yes, you could define all of your types this way, but it’s only necessary at the boundary of the program. Internal functions don’t need to validate inputs if the caller is trusted.

Being able to define a loose input schema at the boundary and then transform it into a shape that your program actually needs is extremely useful.

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#100

Post by chrisfarms »

jerf wrote: post #45
Altern4tiveAcc wrote: post #17

Zod is by far the most ergonomic way to express those ideas in TypeScript these days. I miss it when writing code in other languages. The friction with the rest of the ecosystem is real, though. Most code out there expects you to handle errors with exceptions. I get the impression that polymorphic return types could get in the way of JSC/V8/SpiderMonkey's JIT, but I haven't measured it and I'm not sure of the actual…

I haven't done a lot of Typescript, but I've done at least a couple of month's worth now, and every time I have to type "as" my inner Haskell programmer screams. If I could add one feature to Typescript it would be something like "as" that actually validates the result against the type system and can fail. Unfortunately, that's way, way easier said than done. It's the bad type of keyword that has unbounded runtime co…

The "satisfies" keyword may be what you are missing. Most of the cases I used to need "as" (usually weirdly permissive types from some lib) can be nudged in line with a "satisfies"
Post reply on HN