My favourite feature of Zod is that it, by default (configurable), will remove fields from an object that aren't defined in the schema. So it makes it safe to pass a parsed object straight into your DB without having to pick or omit fields.
Or, on the flip side, you can use it to validate partial database records so that the don’t include sensitive columns and send them straight to an end user
@@GiveMeSomeMeshuggah wouldn't it make more sense to not query that data from the database in the first place? If you already know you cannot show it, why even query it? Or maybe I'm misunderstanding something.
Not so sure if it is really a clickbait, because zod validates values at runtime while giving you the type safety typescript provides, and the later can only enforce type safety at compile time. So he is right imo.
@@tavin136 nothing in the title mentioned zod, nothing in the thumbnail hinted at it. It was "TS BAD!?" click to find out more. Theo loves TS, and the answer was "NO IT ISN"T", so it was the classic bait and switch. If anything you mentioned was hinted at, I'd have watched and enjoyed.
Excellent video. Zod is a masterpiece in engineering. Also now that you mentioned react-hook-form, give some love to react-ts-form - you 'll like what you see, I am sure. P.S. isn't it about to get a clapperboard or somehow introduce the functionality through e.g. hand clapping? The audio isn't entirely synced, at least on my end :S
This is pretty commonplace if you do automated quality control. Strong typing, validation libraries and test tools for business logic go hand-in-hand 😋
It's nice having someone share this information - because I hadn't bothered looking for these solutions when I built my own. Will be useful on future projects (or existing - depends on spare time) 👍
Hey Theo can you make a video for a list of libraries that you always use most of the time in a project. I didn't know a lot of libraries until I got employed with an existing code base. I wish I knew how to use those when I was learning to get things better.
What I like about these validators like Yup and Zod is the way schema is written. It's so easy to read and understand what the schema represents or expects. Also, creating a type from that schema is a super powerful thing. You can just infer type of that schema and use that with useForm() from react-hook-form. Working with forms has never been so nice until I started combining react-hook-form with one of these validator libraries. It also allows developers with less experience to build consistent form experiences. I personally use Yup just because in few instances of validating stuff in frontend forms it just had the ability to add better custom error messages and I could validate enums more easily. For example I get a user role enum type from backend and I loop over that enum to create options for a select dropdown, so that when a new user is created, you can pick a role to assign to it. Using Yup, I can easily validate that role selected is one of expected roles from that enum. Yup just handled these few scenarios in a nicer way and when I compared it to Zod. Zod just couldn't do some of these without too much ridiculous code or not even do something at all, but it's a library that I'll definitely re-evaluate frequently. Since I write frontend only, I really don't need Zod for more complex validations that I might do on backend.
Was about to even ask what the difference between this and yup is. Seems exactly like what yup has been doing for a while but it’s getting so much hype
if (typeof unknown !== 'object' || unknown === null || !('username' in unknown) || typeof unknown.username !== 'string' ....) is how you go from unknown to an object using type narrowing.
This is very interesting, if you couple it with a code generator tool that generates models starting from a self documented api (e.g. swagger) that'd make a nice stack.
Tried to use zod in Express backend ~9m ago. Very useful! It helps to reliably deliver backend workloads to a react frontend (admin panel with product listings).
I feel Zod is the exact opposite philosophy of Reflect MetaData: Make Code generate TypeSafety... wherhas Reflect metadata uses Types to be used as code.... after understing that I feel that ORMs such as TypeOrm who uses it only try to "hack" TS for a purpose that it is not made to, and moved to Prisma. But, after thinkering a bit with Zod I feel it could be the starting point of a nice ORM
Colin explains on his blog why Yup's type inferences are wrong - biggest issue is that "the yup package treats all object properties as optional by default. Yet the inferred type indicates that all properties are required. 😕"
You can actually make typescript "run" if you use something like typia, which validates json against your typescript types. Getting it working with tRPC is a little tedious though since it's geared towards zod so much
Zod has better type-inference than Yup last I looked. Otherwise, not a lot of differences. Both are great libraries. I LOVE Zod's type-inference, though. One thing I hated about Typescript was having to build types AND validators against my interfaces, and knowing that if they fell out of sync all hell could break loose. Zod solves that.
What about sinclair/Typebox? It is 5 times more downloaded than Zod people are talking about, 2 times more than Joi that I am using but lack type inferring.
Sinclair keeps bugging people in reddit to swap to typebox, but he got really whiny at me and deleted a bunch of his comments when I tried to discuss it with him. That genuinely concerns me about the long-term life of the library because that kind of behavior has been a predictor of project-abandonment in the past. A lot of people have mentioned that typebox's download-count is artificially large because it is in a common `jest` dependency and jest stacks are downloaded automatically a LOT... so I don't know if I'd say typebox is anywhere near as stable/big as Zod yet. Of course, Zod is pretty small, too, compared to ajv. Flip-side, typebox has 22 contributors last I looked. Far fewer than zod, but "not 1 or 2". I think if the library felt less like OSS marketing hype and had trpc integration (or documented trpc integration), I would consider trying it out.
there is a cocept called "make illegal states unrepresentable” comming from functional languages like fsharp/haskell/scala using the type system. not sure if that is applicable for ts/js, but i would like to hear your opinion on it.
Is there a need to use ZOD for graphql response and rest-api response? Personally i think there is no need for graphql, but for rest-api it's considerable, because the response could not be validated on BE side. WDYT?
You mentioned, it gives the ability to write a validator one time in one place to validate both frontend and backend, how would you implement it in a monolith contains backend with express and frontend built by (any), would you export validations to external npm package? or how would you structure the project
Since your app is a monolith, both the backend and the front end are in the same code base. I guess all you’d have to do is import the validator in both files, and let SSR do its thing. Could be wrong, though.
I recently have been doing this with my projects, and I think I found a nice way to do it! I can make a demo example for you if this doesn't help explain it very well. First I add a tsconfig.json file to the root of my project. You can allow the TypeScript compiler to check your vanilla JavaScript files too, by setting both the `compilerOptions` properties `allowJS` and `checkJS` to true. This will start showing type errors for your code right in your editor, just like a full TypeScript file does. Then, you can go through each of your existing files, and add JSDoc type annotation comments, which are usable by the TypeScript compiler. Eventually, once you have all of your types specified using JSDoc, it is much easier to move the files over from `.js` to `.ts`, because your already took care of all the type errors. In your editor, it may give you an option to `infer types from JSDoc`, after your rename your files to `.ts`. This was a nice way for me to learn how to add type definitions before having to learn how the TypeScript syntax works, as the two are kind of separate steps in my mind. There may be some confusing parts to work out along the way, but this has seemed to work very well for my own codebases. Hopefully this helped at least a little bit! Here's some resources that I found to help me find this out: www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html www.mobiquity.com/insights/typescript-to-javascript-with-jsdoc-and-back
I think it is meant to say, "hopefully you won't need to validate an external API" (regardless of with zod or somehow else) since a good API would not randomly change the schema returned and break your client. They should more likely version the API if necessary.
interesting vid theo. does it matter how many libraries we use, as long as they are useful? my college professor told us to reinvent the wheel every time because "libraries are inefficient for what you need" but i feel like that makes no sense because libraries are meant to help...
Your professor might have a bit of "not invented here" syndrome. On a more serious note: any library you use, and any code you write is a liability. You must use your judgement to decide between writing it yourself, or choosing a library.
It'd be very nice to show exact flows of Yup before just throwing it to the bin :) Especially since there already was one video about Zod (general deserves it though)
I don't know... Maybe for some backend object definitions Zod might be fine, but on Front for forms validation, Yup is way more better! Zod is really pain in the ass for validating complex forms, whre yup has some handy features.
Hot take: superstruct is superior to Zod. You should seriously consider it when choosing a validation library. It is first class supported by tRPC, has awesome TS experience and more extensible design paradigm (composition instead of fluent). It also has a smaller bundle size than Zod and runs faster.
It's not in scope of responsibility of TS to check string's length or validate as email. There is also class-validator doing same thing btw. Typed languages only validate types, not values!
Fellow YC alum here. Gotta respectfully disagree with you. Runtime type checking is a recipe for disaster. I got my first post Mortem at Airbnb for someone thinking this was a good idea (visa vi an internal ruby gem). 500s do not benefit users! Data validation is a good idea, but is not the same thing as type checking. One of the biggest benefits of isomorphic typed systems is that in theory type validation becomes unnecessary at runtime (even for rpc and http calls). Confusing data validation and type safety is one of the biggest confusions I notice in junior and mid level engineers using typescript these days.
This is a weird mirror-image take to my own. I hated on Typescript *because* people confused data validation with type safety. Type safety serves no purpose for your external interfaces or any interfaces that might go out of sync. Because of that, I used to prefer javascript with runtime type checking. That's sorta the "classic" way. You're not wrong that 500s don't benefit users, but it's still usually better than processing a bad request as if it were a good one. It's a balance, and something like Zod can be implemented to be as flexible as you can allow (only validating the pieces you need) if that is a real concern. But then, in my almost-20-years in the industry, I've never touched an API that was allowed to reach prod without some sort of runtime type checking. The reason I like zod as a Runtime type-checker is because of its compile-time inferences. Some of your "500" situations could actually get caught by the typescript compiler.
Zod is great! Why do I have the impression that Javascript it's all about typing now? Since Typescript came in, all the Javascript's biggest concerns is suddently typing. Anyway, I still think Typescript makes a lot of sence and packages like Zod and Trpc are also essencial for the industry.
@@snehanshuphukon728 I think Typescript sometimes gives people a false feeling of safety. As many people I come across mistake typescript running on execution. Also, a wrongly assumed/typed variable or function return is way more prone to lead to errors than the Javascript equivalent where you take for granted that you have to handle every type or data structure. However, if you don't enforce types and are aware of when and where it acts, Typescript is great.
nope, it's completely irrelevant to class, don't treat concept behind based on the syntax. it's more about static/dynamic and runtime/compile type checking inside or between application like frontend &backend. Though I felt the runtime check from zod or yup might have performance tradeoff. Just not sure how much it will cost.
what's the point of typescript if you're using a 3rd party library for typechecking? I get ts doesn't typecheck on runtime, which zod does but it just does not make any sense, it's just more logical to use a normal language with types rather than do this kind of crap.
No. A lots of BE frameworks have their own specification to providing public api. U cannot force them to do your job. Also it might be not TS Backend at all U should generate validators from OpenAPI Spec/GQL via codegen, or just manualy create them
We do this for an internal SDK that publishes and consumes kafka messages. The schema is stored in the SDK and you can't publish a message for a specific topic if parsing throws.
I do agree that typescript can be over kill But 2 videos ago you said typescript is good without the types, and it's not why you should use it, and now this 😂😂 Just admit you have an agenda with JS Ps I fully agree I never use typescript as typescript, I just use it in the background, and if a data type needs to be that type, I use their types in production with packages like this. Especially before adding it to a database... I thought it was common sense though
I think Theo's argument is that as a consumer of libraries and built-in APIs, you don't need the Typescript-specific syntax 90% of the time. The language server is just going to run for you in the background and catch the majority of issues with just type inference. And most of the time when you do need to add typing, it's to add definitions to "boundary types" that can't easily be inferred - function parameters, type parameters for things like maps/arrays, the return type of fetch. Compile-time type safety is the only thing you're shooting for - screwing around with the type layer and making all these convoluted types is fun, but isn't always needed to reach that goal. As usual, Theo is vocalizing his opinions in a really strong way that isn't really open to nuance. I think he's right that most developers can get away with TypeScript that mostly looks like JavaScript, but when you do need to make something really general-use that isn't available as a library, that knowledge of how to work with the type layer - how to treat it as a functional language in itself - is the only way to make things work without lying to the compiler.
Javascript/Typescript are madness. When you need a library to ensure type safety... so glad I left web dev. I sometimes wonder if the only people who use javascript/typescript learned them as their first languages and just don't know any different.
Crazy how people are shocked with TS now. Solutions like zod are just patches to things software engineers should already be checking but dont because they dont understand what TS is actually doing and trust it. TS is NOT a language, its a tool same level as a linter. You dont need zod. You need common sense and programming skills.
Yup doesn't play nicely with TypeScript. You can infer types with Zod really easily and accurately. So if you have a function where the params are validated with Zod, you can infer the type from the schema so you have type checking for the dev and runtime validation.
@@praneshkmr you can always make your own test utils to cover any variation of data type , schema , data consistency and/or dependencies using tests . That wasn't my point .
My favourite feature of Zod is that it, by default (configurable), will remove fields from an object that aren't defined in the schema. So it makes it safe to pass a parsed object straight into your DB without having to pick or omit fields.
How tf did I not know that.
Or, on the flip side, you can use it to validate partial database records so that the don’t include sensitive columns and send them straight to an end user
@TomDoesTech would love to see that in your upcoming video :D
@@GiveMeSomeMeshuggah wouldn't it make more sense to not query that data from the database in the first place? If you already know you cannot show it, why even query it? Or maybe I'm misunderstanding something.
@@GiveMeSomeMeshuggah that is brilliant!
I love you, dude, but why the recent clickbait storm?
bills
Recent? Lol clickbait is the foundation of this channel
Not so sure if it is really a clickbait, because zod validates values at runtime while giving you the type safety typescript provides, and the later can only enforce type safety at compile time. So he is right imo.
marketing
@@tavin136 nothing in the title mentioned zod, nothing in the thumbnail hinted at it. It was "TS BAD!?" click to find out more. Theo loves TS, and the answer was "NO IT ISN"T", so it was the classic bait and switch. If anything you mentioned was hinted at, I'd have watched and enjoyed.
Thanks for this kind of content. Really useful!
Excellent video. Zod is a masterpiece in engineering. Also now that you mentioned react-hook-form, give some love to react-ts-form - you 'll like what you see, I am sure.
P.S. isn't it about to get a clapperboard or somehow introduce the functionality through e.g. hand clapping? The audio isn't entirely synced, at least on my end :S
This is pretty commonplace if you do automated quality control. Strong typing, validation libraries and test tools for business logic go hand-in-hand 😋
It's nice having someone share this information - because I hadn't bothered looking for these solutions when I built my own.
Will be useful on future projects (or existing - depends on spare time)
👍
Hey Theo can you make a video for a list of libraries that you always use most of the time in a project. I didn't know a lot of libraries until I got employed with an existing code base. I wish I knew how to use those when I was learning to get things better.
What I like about these validators like Yup and Zod is the way schema is written. It's so easy to read and understand what the schema represents or expects. Also, creating a type from that schema is a super powerful thing. You can just infer type of that schema and use that with useForm() from react-hook-form. Working with forms has never been so nice until I started combining react-hook-form with one of these validator libraries. It also allows developers with less experience to build consistent form experiences.
I personally use Yup just because in few instances of validating stuff in frontend forms it just had the ability to add better custom error messages and I could validate enums more easily. For example I get a user role enum type from backend and I loop over that enum to create options for a select dropdown, so that when a new user is created, you can pick a role to assign to it. Using Yup, I can easily validate that role selected is one of expected roles from that enum. Yup just handled these few scenarios in a nicer way and when I compared it to Zod. Zod just couldn't do some of these without too much ridiculous code or not even do something at all, but it's a library that I'll definitely re-evaluate frequently. Since I write frontend only, I really don't need Zod for more complex validations that I might do on backend.
Was about to even ask what the difference between this and yup is. Seems exactly like what yup has been doing for a while but it’s getting so much hype
prisma+tRPC+zod is pretty nice combo :D
yup without strict() is useless and actually was a problem for me. It actually accepts array of strings if you have a .string()
I also use yup because zod produces some strange type errors
if (typeof unknown !== 'object' || unknown === null || !('username' in unknown) || typeof unknown.username !== 'string' ....)
is how you go from unknown to an object using type narrowing.
That "typeof unknown === null" would just be "unknown === null". The typeof operator always returns a string and doesn't have a null case.
@@DubiousNachos oh yeah, you're right. That was a typo.
We've come full circle! Need to bring a statically typed language for web haha
This is very interesting, if you couple it with a code generator tool that generates models starting from a self documented api (e.g. swagger) that'd make a nice stack.
Tried to use zod in Express backend ~9m ago. Very useful! It helps to reliably deliver backend workloads to a react frontend (admin panel with product listings).
Great video, looking forward to add it to my tool belt
I feel Zod is the exact opposite philosophy of Reflect MetaData: Make Code generate TypeSafety... wherhas Reflect metadata uses Types to be used as code.... after understing that I feel that ORMs such as TypeOrm who uses it only try to "hack" TS for a purpose that it is not made to, and moved to Prisma. But, after thinkering a bit with Zod I feel it could be the starting point of a nice ORM
Last time I checked, Zod had big performance issues. I hope they solved that. It might be worth giving Zod another chance
Colin explains on his blog why Yup's type inferences are wrong - biggest issue is that "the yup package treats all object properties as optional by default. Yet the inferred type indicates that all properties are required. 😕"
You can actually make typescript "run" if you use something like typia, which validates json against your typescript types.
Getting it working with tRPC is a little tedious though since it's geared towards zod so much
prisma+tRPC+zod is pretty nice combo :D
Great video, it help me to know how zod works!!
Damn... your thumbnail game is on next level 🤟
First 3 seconds = 1 like. Zod is always worth a like. A thousand likes.
But your face, your hair, your presence theo - priceless.
Added to my project now :) thanks!
thanks for the video!
This oddly feels like yup. Haven’t dug into the differences but that’s my thought when I saw Zod for the first time
Zod has better type-inference than Yup last I looked. Otherwise, not a lot of differences. Both are great libraries. I LOVE Zod's type-inference, though.
One thing I hated about Typescript was having to build types AND validators against my interfaces, and knowing that if they fell out of sync all hell could break loose. Zod solves that.
Parse, don't validate!
The one for typescript is class-validator. By itself typescript does not validate the objects at runtime
damn
u makin me hyped to learn this
great explanation!
What about sinclair/Typebox? It is 5 times more downloaded than Zod people are talking about, 2 times more than Joi that I am using but lack type inferring.
Sinclair keeps bugging people in reddit to swap to typebox, but he got really whiny at me and deleted a bunch of his comments when I tried to discuss it with him. That genuinely concerns me about the long-term life of the library because that kind of behavior has been a predictor of project-abandonment in the past. A lot of people have mentioned that typebox's download-count is artificially large because it is in a common `jest` dependency and jest stacks are downloaded automatically a LOT... so I don't know if I'd say typebox is anywhere near as stable/big as Zod yet. Of course, Zod is pretty small, too, compared to ajv.
Flip-side, typebox has 22 contributors last I looked. Far fewer than zod, but "not 1 or 2". I think if the library felt less like OSS marketing hype and had trpc integration (or documented trpc integration), I would consider trying it out.
Nobody, I mean nobody does the typescript better than me. I mean nobody.
there is a cocept called "make illegal states unrepresentable” comming from functional languages like fsharp/haskell/scala using the type system. not sure if that is applicable for ts/js, but i would like to hear your opinion on it.
I never used zod, but I used yup a long time ago. if my memory is not failing me, didn't yup do the same things?
Is there a need to use ZOD for graphql response and rest-api response?
Personally i think there is no need for graphql, but for rest-api it's considerable, because the response could not be validated on BE side. WDYT?
Nope graphQL frameworks will do all your runtime validation for you typically.
You mentioned, it gives the ability to write a validator one time in one place to validate both frontend and backend, how would you implement it in a monolith contains backend with express and frontend built by (any), would you export validations to external npm package? or how would you structure the project
Since your app is a monolith, both the backend and the front end are in the same code base. I guess all you’d have to do is import the validator in both files, and let SSR do its thing. Could be wrong, though.
Inference part iz amazing.
Yup was a game changer. Zod is even better.
If you were to start TS again, how would you migrate a JS project to a TS? I am looking into migrating mine to TS and start learning on the go.
I recently have been doing this with my projects, and I think I found a nice way to do it! I can make a demo example for you if this doesn't help explain it very well.
First I add a tsconfig.json file to the root of my project. You can allow the TypeScript compiler to check your vanilla JavaScript files too, by setting both the `compilerOptions` properties `allowJS` and `checkJS` to true. This will start showing type errors for your code right in your editor, just like a full TypeScript file does.
Then, you can go through each of your existing files, and add JSDoc type annotation comments, which are usable by the TypeScript compiler.
Eventually, once you have all of your types specified using JSDoc, it is much easier to move the files over from `.js` to `.ts`, because your already took care of all the type errors. In your editor, it may give you an option to `infer types from JSDoc`, after your rename your files to `.ts`.
This was a nice way for me to learn how to add type definitions before having to learn how the TypeScript syntax works, as the two are kind of separate steps in my mind.
There may be some confusing parts to work out along the way, but this has seemed to work very well for my own codebases. Hopefully this helped at least a little bit!
Here's some resources that I found to help me find this out:
www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html
www.mobiquity.com/insights/typescript-to-javascript-with-jsdoc-and-back
@@offroaders123 WOW... THANKS A LOT. You have been an incredible help. Wish more people would respond that detailed to messages! 😃😁
@@GabrielMartinez-ez9ue So glad I could help! I was worried that was too long too, haha.
This turns out to be a copilot ad lol
Great video! I'm curious on why you say we hopefully won't need zod for validating external APIs though
I think it is meant to say, "hopefully you won't need to validate an external API" (regardless of with zod or somehow else) since a good API would not randomly change the schema returned and break your client. They should more likely version the API if necessary.
Let's get that platinum youtube button.
Thanks!
Hey, I have a question, is the T3 stack SEO friendly? also is it good for medium to big app?
I really need to see the results of running the code to understand it. The lack of it killed this vid for me.
interesting vid theo. does it matter how many libraries we use, as long as they are useful? my college professor told us to reinvent the wheel every time because "libraries are inefficient for what you need" but i feel like that makes no sense because libraries are meant to help...
Your professor might have a bit of "not invented here" syndrome.
On a more serious note: any library you use, and any code you write is a liability. You must use your judgement to decide between writing it yourself, or choosing a library.
It'd be very nice to show exact flows of Yup before just throwing it to the bin :) Especially since there already was one video about Zod (general deserves it though)
Read Colin's essay about the designing of Zod, there he mentions Yup's type inference is wrong.
Which VS Code theme is this, can somebody tell me please?
Are you mostly using zod for user input and in API routes to check incoming body data?
I don't know... Maybe for some backend object definitions Zod might be fine, but on Front for forms validation, Yup is way more better! Zod is really pain in the ass for validating complex forms, whre yup has some handy features.
Zod is amazing!
But don't look at the source if you want to sleep at night 😅
Hot take: superstruct is superior to Zod. You should seriously consider it when choosing a validation library. It is first class supported by tRPC, has awesome TS experience and more extensible design paradigm (composition instead of fluent). It also has a smaller bundle size than Zod and runs faster.
Did you develop superstruct lol
@@kyleroach2581 I just think it’s very underrated
So, Zod is used in addition to a typescript setup, or does it replace the necessity of Typescript in a project?
It's used in addition to TypeScript.
let me guess, it's about zod
It's not in scope of responsibility of TS to check string's length or validate as email. There is also class-validator doing same thing btw.
Typed languages only validate types, not values!
Ts also can’t validate incoming unknown data at runtime.
Zod does both validation and creates the ts types
nice shirt, theo
My stupid explanation would be.. (front end validation + backend validation) * simplicity = zod.
Reminds me of Pydantic for Python
5:07 demontized
Fellow YC alum here. Gotta respectfully disagree with you. Runtime type checking is a recipe for disaster. I got my first post Mortem at Airbnb for someone thinking this was a good idea (visa vi an internal ruby gem). 500s do not benefit users! Data validation is a good idea, but is not the same thing as type checking. One of the biggest benefits of isomorphic typed systems is that in theory type validation becomes unnecessary at runtime (even for rpc and http calls). Confusing data validation and type safety is one of the biggest confusions I notice in junior and mid level engineers using typescript these days.
I've seen devs confusing this maybe twice ever but i'll keep an eye out for it
This is a weird mirror-image take to my own.
I hated on Typescript *because* people confused data validation with type safety. Type safety serves no purpose for your external interfaces or any interfaces that might go out of sync.
Because of that, I used to prefer javascript with runtime type checking. That's sorta the "classic" way. You're not wrong that 500s don't benefit users, but it's still usually better than processing a bad request as if it were a good one. It's a balance, and something like Zod can be implemented to be as flexible as you can allow (only validating the pieces you need) if that is a real concern. But then, in my almost-20-years in the industry, I've never touched an API that was allowed to reach prod without some sort of runtime type checking.
The reason I like zod as a Runtime type-checker is because of its compile-time inferences. Some of your "500" situations could actually get caught by the typescript compiler.
Zod is great!
Why do I have the impression that Javascript it's all about typing now? Since Typescript came in, all the Javascript's biggest concerns is suddently typing. Anyway, I still think Typescript makes a lot of sence and packages like Zod and Trpc are also essencial for the industry.
JavaScript is a powerful language. Typescript makes it safe and fun to use. So it being all about typing is a good thing in my opinion.
@@snehanshuphukon728 I think Typescript sometimes gives people a false feeling of safety. As many people I come across mistake typescript running on execution. Also, a wrongly assumed/typed variable or function return is way more prone to lead to errors than the Javascript equivalent where you take for granted that you have to handle every type or data structure.
However, if you don't enforce types and are aware of when and where it acts, Typescript is great.
@@snehanshuphukon728Is typescript really fun ? 🫤
sounds a lot like Dart
zod doesnt stop at the first error for each field and its a waste of performance
I wrote my own validator that just uses the built in classes in js, and works fine for me
You should release it as an npm package
I personally prefer Yup, not really for any other reason than being able to use it with Formik natively.
You should probably start using react-hook-form first
Are we just reinventing C#/Java classes at this point?
nope, it's completely irrelevant to class, don't treat concept behind based on the syntax.
it's more about static/dynamic and runtime/compile type checking inside or between application like frontend &backend.
Though I felt the runtime check from zod or yup might have performance tradeoff. Just not sure how much it will cost.
They should add this into TRPC without needing any extra line of code. Okay, maybe a flag to enable/disable it.
What do you mean? You can use Zod schemas with tRPC natively
what's the differebce with, "Yup?"
TS support
Zod is great, I'm surprised to see so many negative comments here.
Where is kal el?
Perso, I never found any utility from TS.
zod is great but it's slow af
edit: I mean it makes Typescript slow so stuff like intellisense take a long time to popup
5:07 😂
Sounds like serde in rust, but serde is actually better
Looks like yup with better npm trends as zod
what's the point of typescript if you're using a 3rd party library for typechecking? I get ts doesn't typecheck on runtime, which zod does but it just does not make any sense, it's just more logical to use a normal language with types rather than do this kind of crap.
Anyone else think SDKS / APIs/ other libs should ship with zod schemas to power their TS types? Too cumbersome?
No. A lots of BE frameworks have their own specification to providing public api. U cannot force them to do your job. Also it might be not TS Backend at all
U should generate validators from OpenAPI Spec/GQL via codegen, or just manualy create them
We do this for an internal SDK that publishes and consumes kafka messages. The schema is stored in the SDK and you can't publish a message for a specific topic if parsing throws.
Isn't `ajv` and `typia` is better players in this field ?
I do agree that typescript can be over kill
But 2 videos ago you said typescript is good without the types, and it's not why you should use it, and now this 😂😂
Just admit you have an agenda with JS
Ps I fully agree I never use typescript as typescript, I just use it in the background, and if a data type needs to be that type, I use their types in production with packages like this.
Especially before adding it to a database...
I thought it was common sense though
I think Theo's argument is that as a consumer of libraries and built-in APIs, you don't need the Typescript-specific syntax 90% of the time. The language server is just going to run for you in the background and catch the majority of issues with just type inference.
And most of the time when you do need to add typing, it's to add definitions to "boundary types" that can't easily be inferred - function parameters, type parameters for things like maps/arrays, the return type of fetch.
Compile-time type safety is the only thing you're shooting for - screwing around with the type layer and making all these convoluted types is fun, but isn't always needed to reach that goal.
As usual, Theo is vocalizing his opinions in a really strong way that isn't really open to nuance. I think he's right that most developers can get away with TypeScript that mostly looks like JavaScript, but when you do need to make something really general-use that isn't available as a library, that knowledge of how to work with the type layer - how to treat it as a functional language in itself - is the only way to make things work without lying to the compiler.
I am much bigger fan of fp-ts. Upcoming fp-ts/schema is even more breathtaking than Zod! What do you think of it? 😊
I want to understand fp-ts but the docs- Q_Q
Real talk: this works even better in Rust
Javascript/Typescript are madness. When you need a library to ensure type safety... so glad I left web dev. I sometimes wonder if the only people who use javascript/typescript learned them as their first languages and just don't know any different.
First, nerds
So with zod, we have to duplicate typescript. Tremendous stupid. What is way cooler? ajv
If want to assert every type in a dynamically typed language, then it's better to learn static languages.
Exactly. JavaScript developers are terrible devs. 1,000 libraries just to fix JavaScript.
Crazy how people are shocked with TS now. Solutions like zod are just patches to things software engineers should already be checking but dont because they dont understand what TS is actually doing and trust it.
TS is NOT a language, its a tool same level as a linter.
You dont need zod. You need common sense and programming skills.
Or..... use rust 🤓
Or at least Purescript which is 100% type safe and compiles to JS, Go and C++
zod isnt that great tbh
well isnt yup doing the same thing !
Watch like 45 more seconds and I directly mention this lmao
@@t3dotgg i did xd
I dont think we can do discriminated union with Yup
Yup doesn't play nicely with TypeScript. You can infer types with Zod really easily and accurately. So if you have a function where the params are validated with Zod, you can infer the type from the schema so you have type checking for the dev and runtime validation.
@@praneshkmr you can always make your own test utils to cover any variation of data type , schema , data consistency and/or dependencies using tests . That wasn't my point .
schemawax is my favorite of these kind of libraries
Purescript. There problem solved
I am absolutely sure that zod deserves $ alias in todays JS world like it used to be for jQuery
Please check deepkit. Thats another whole new level!
I made a video about ZOD and viewers doesn’t seem to like this library (according my channel) 🥲
I read the comments on your video and they are ummm, interesting. Great video btw