No .partial(), .deepPartial(), .merge() and others after using .refine() on ZodObject
See original GitHub issueThe refine
method on a ZodObject instance returns a ZodEffects instance which lacks any of the object methods. It broke some code after migrating to v3.
I don’t know the reasons behind this change, I guess it’s to support chaining multiple refine
and transform
calls, but maybe there’s a way to keep the original methods.
It should also benefit another schema types’ methods.
Issue Analytics
- State:
- Created 2 years ago
- Comments:8 (1 by maintainers)
Top Results From Across the Web
RFC: Refactoring transformers and Zod 3 · Issue #264 - GitHub
If I do a merge() on two types I can still examine their shape. I'm using the library for both parsing and for...
Read more >Untitled
For example, you can define a custom validation check on _any_ Zod schema with `.refine`: ```ts const myString = z.string().refine(val => val.length <=...
Read more >zod - npm
Zod is a TypeScript-first schema declaration and validation library. I'm using the term "schema" to broadly refer to any data type/structure, from a...
Read more >How to merge partial properties with the default values of a ...
Be aware of mutating references when merging objects like this. Both methods above will clone da and pa respectively to one level of...
Read more >Designing the perfect Typescript schema validation library
When I started my quest to find the ideal schema declaration/validation library, I assumed the ... and merge them with t.intersection() .
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yeah, I think the only way to avoid that is to use naming conventions and comments like:
@kevlugli
Your example demonstrates the difficulty of a general solution.
refine
assumes that the input type is not-partial, so you would get runtime errors when trying to access undefined fields in your refinement function. Take this example given your schemas:In your particular refinement’s case, you’re testing
data.countryId === "US"
so you don’t fall into a runtime error, but imagine you wanted to normalize the string first likedata.countryId.toUppercase() === "US"
, the compiler would not be able to tell you that it’s invalid since the type ofdata
is not partial.I know it’s annoying to have to respecify refinements, but I think if you end up transforming a type that you also need to refine, you’ll want to maybe share refinements that are defensive and applicable to all of the possible input values.
Then you can export an unrefined version that you can call
.partial().refine(usZipcodeRefinement)
on and a refined version that you can use on it’s own.