3 ms·

I think only (3) lands as a good point. And it is a big weakness of Typescript. Practically, any TS application is going to get data from an API or DB. You r

by treis 3y ago

I think only (3) lands as a good point. And it is a big weakness of Typescript. Practically, any TS application is going to get data from an API or DB. You really would like to validate the shape of this data and TS offers little here. Hence the explosion of tools like zod to go to/from TS type definition to validation rules. Feels very wrong to have to add in a type manipulation library to a language that is basically only Types.

epolanski 3y ago
I'm not understanding the point. In every single decent language with a static type system you'll have to convince the type checker that data coming from outside the boundaries is of a certain shape by parsing it. If you're not doing it, then you are implicitly assuming it's of some type and you risk runtime type errors. E.g. in Elm you do have to parse every single thing coming in from outside the boundaries both from http requests or other external ports.
- treis 3y ago
  >risk runtime type errors. This is the part that's missing. Or more completely there's no runtime types at all. So you can't do stuff like: result = fetch.... if(result is User){ return result }else{ Throw error } The mechanism TS gives you to do that is essentially recreating all your type rules in a validation. Which is keeping the same information in two places and risks them getting out of sync. Most people pick up a library that generates the types and validations for you to solve this. Which works but it's kind of weird that you have to.
  - epolanski 3y ago
    > Most people pick up a library that generates the types and validations for you to solve this. Which works but it's kind of weird that you have to. Why would it? Which static languages include automatic parsing at boundaries? Elm sort of does on ports, but that's like the only example I can think of, I'm perfectly sure that I may not know enough about it.
evilduck 3y ago
It's not a must, you can absolutely model IO and roll your own class validation/serializers methods and get both build time type safety and runtime validations without including a library for it. It's typical old school JS style validation we've done for decades with just some stylistic adaptations to stay type safe. However, grabbing Zod or io/ts is a lot less work and with tools like https://quicktype.io/typescript https://quicktype.io/typescript or https://transform.tools/json-to-zod https://transform.tools/json-to-zod you can paste in an API response, copy over a validator and export a type. My homegrown validator classes won't be nearly as clean or as quick.

by treis 3y ago

epolanski 3y ago

I'm not understanding the point. In every single decent language with a static type system you'll have to convince the type checker that data coming from outside the boundaries is of a certain shape by parsing it. If you're not doing it, then you are implicitly assuming it's of some type and you risk runtime type errors. E.g. in Elm you do have to parse every single thing coming in from outside the boundaries both from http requests or other external ports.

treis 3y ago
>risk runtime type errors. This is the part that's missing. Or more completely there's no runtime types at all. So you can't do stuff like: result = fetch.... if(result is User){ return result }else{ Throw error } The mechanism TS gives you to do that is essentially recreating all your type rules in a validation. Which is keeping the same information in two places and risks them getting out of sync. Most people pick up a library that generates the types and validations for you to solve this. Which works but it's kind of weird that you have to.
- epolanski 3y ago
  > Most people pick up a library that generates the types and validations for you to solve this. Which works but it's kind of weird that you have to. Why would it? Which static languages include automatic parsing at boundaries? Elm sort of does on ports, but that's like the only example I can think of, I'm perfectly sure that I may not know enough about it.

evilduck 3y ago

It's not a must, you can absolutely model IO and roll your own class validation/serializers methods and get both build time type safety and runtime validations without including a library for it. It's typical old school JS style validation we've done for decades with just some stylistic adaptations to stay type safe. However, grabbing Zod or io/ts is a lot less work and with tools like https://quicktype.io/typescript https://quicktype.io/typescript or https://transform.tools/json-to-zod https://transform.tools/json-to-zod you can paste in an API response, copy over a validator and export a type. My homegrown validator classes won't be nearly as clean or as quick.