z.strict() fixed a nasty bug for me this morning.
You should probably be using it on most of the schemas that handle outside data.
Here's the bug 🧵
I had a form where I was marking the date a post was posted. I was expecting a key of `postedAt`, with an optional datetime.
Except, in my form, I had gotten the `name` field wrong:
By default, Zod is happy to accept extra keys in the input. Those keys then get stripped from the output.
So, passing `datePosted` meant that changing the date on the frontend would never make it to the database.
The fix here is to make Zod warn me when I was passing excess keys by marking the schema as `strict`.
This makes sure any caller of your API is passing the right keys.
I can think of way more cases where I'd want `strict` than not. I'm going to start adding it to all the schemas that handle outside data.
What do you think?
Want more juicy nuggets? I've got a newsletter:
z.strict() fixed a nasty bug for me this morning.
You should probably be using it on most of the schemas that handle outside data.
Here's the bug 🧵 I had a form where I was marking the date a post was posted. I was expecting a key of `postedAt`, with an optional datetime. Except, in my form, I had gotten the `name` field wrong: By default, Zod is happy to accept extra keys in the input. Those keys then get stripped from the output.
So, passing `datePosted` meant that changing the date on the frontend would never make it to the database. The fix here is to make Zod warn me when I was passing excess keys by marking the schema as `strict`.
This makes sure any caller of your API is passing the right keys. I can think of way more cases where I'd want `strict` than not. I'm going to start adding it to all the schemas that handle outside data.
What do you think?Want more juicy nuggets? I've got a newsletter:
yes
