I decided to mess around with Zod in a test project, and it seemed very convenient, at least at first glance. If this ends up working out for what I need it to do, I might convert my entire recent project to it. It might fix a couple inconvenient bugs there
Before knowing abohut Zod, I was used to validate everything by myself, then I tried Zod in a test project and I can tell, it is very easy to grow with zod, the difficulty doesn't increase together, it feels you're just creating Types/Interfaces in a more security way, I really recommend you to do that.
@@fagnersales532 strict types is basically the whole point of my project so if I can close a few gaps for what I couldn't do natively, it'll be awesome
This was very illuminating! In a similar vein I'd love to understand how something like ts-pattern works under the hood. Like how to implement a mini pattern-matching library.
Great video! I'd suggest returning the parsed value of arg from the validate function so that it strips out properties that were not defined in the schema like zod does.
How does Nest's Dependency Injection and some other cool features work together? They use extremely good separation of concerns by using modules for everything. Any kind of under the hood analysis will be really cool!
Zod uses "parse, don't validate" as a tagline. Just validating and then asserting a type leaves some room for logic errors in the validator. Actually having to construct a value corresponding to the parser's return type makes the code more robust against such errors.
Great video, I am interesting to know how JSON object config parsing libraries work with big complex objects which multiple optional and default properties
It's kind of strange that typescript isn't able to make the connection between : 'asserts value is string' and 'if (typeof value !== "string") throw' since it knows what both statements do individually
I have ran into this a bunch. I had to put a return in the same block after throwing an error so after that block TypeScript would give me the correct type.
Actually, it was a validation library I wrote a few years back to use in all my projects, back and frontend, and it had its unique api, so when I ran into zod in January and liked it's api design, I decided to add a similar api into my library
I decided to mess around with Zod in a test project, and it seemed very convenient, at least at first glance. If this ends up working out for what I need it to do, I might convert my entire recent project to it. It might fix a couple inconvenient bugs there
Before knowing abohut Zod, I was used to validate everything by myself, then I tried Zod in a test project and I can tell, it is very easy to grow with zod, the difficulty doesn't increase together, it feels you're just creating Types/Interfaces in a more security way, I really recommend you to do that.
@@fagnersales532 strict types is basically the whole point of my project so if I can close a few gaps for what I couldn't do natively, it'll be awesome
This was very illuminating! In a similar vein I'd love to understand how something like ts-pattern works under the hood. Like how to implement a mini pattern-matching library.
Great video! I'd suggest returning the parsed value of arg from the validate function so that it strips out properties that were not defined in the schema like zod does.
Zod's philosophy of "parse, don't validate" naturally leads to that being the output.
How does Nest's Dependency Injection and some other cool features work together? They use extremely good separation of concerns by using modules for everything. Any kind of under the hood analysis will be really cool!
Zod uses "parse, don't validate" as a tagline. Just validating and then asserting a type leaves some room for logic errors in the validator.
Actually having to construct a value corresponding to the parser's return type makes the code more robust against such errors.
when I create the assertion function like you did, I get an error - 'val' is not defined. on the line 'asserts val is a string' . Why?
Make sure that you use the same name as the argument of the assertion function. So
function assertsString(val: unknown): asserts val is string {...}
that's cool man 😎
each video => more knowledge for me 😂
thanks 🙏 amazing videos
This was great - thank you!
Great video, I am interesting to know how JSON object config parsing libraries work with big complex objects which multiple optional and default properties
It's kind of strange that typescript isn't able to make the connection between :
'asserts value is string'
and
'if (typeof value !== "string") throw'
since it knows what both statements do individually
I have ran into this a bunch. I had to put a return in the same block after throwing an error so after that block TypeScript would give me the correct type.
You can return an actual string rather than a disconnected type assertion, turning it from a validator into a parser. This is what Zod does.
Nice channel!
Isn't it `arg as keyof S` in line 42 instead of any? Thank you!
you can use the "satisfy" correct ?
Hmm, probably! What do you have in mind?
How recoil reaches fine grained update? How jest is working (except especially)?
+1
Universal quantification
I use my own implementation (:
Too late, already built mine in January 😂.. Name on npm is valleyed
Actually, it was a validation library I wrote a few years back to use in all my projects, back and frontend, and it had its unique api, so when I ran into zod in January and liked it's api design, I decided to add a similar api into my library
👀👍👍
I dislike how Zod does things backwards. Zod should enforce validation to follow a type, rather than making up a type from validation.
You will bow to Zod lol
how are you so condescending and not condescending at all at the same time?
Lol I hope that’s a good thing? I just try to explain it how I’d want to hear it if I was learning it for the first time.
he's not condescending at all... he's a very patient and thorough teacher.
How is he condencending? Oh, you mean the school teacher like tone of voice?