zod
zod copied to clipboard
colinhacks
[#1287] add params to transform and refine
This PR solve the issue #1287 by adding the ability to add a params object as optional argument to parse functions, this params argument will be available in transform and refine callbacks to perform more customizable data checks and transformation.
I will extend this PR with a few doc when I'll get some time.
Deploy Preview for guileless-rolypoly-866f8a ready!
Built without sensitive environment variables
| Name | Link |
|---|---|
| Latest commit | cf91eae0fae994a87167535755c30f4a319663e1 |
| Latest deploy log | https://app.netlify.com/sites/guileless-rolypoly-866f8a/deploys/631710412937a200083f6448 |
| Deploy Preview | https://deploy-preview-1288--guileless-rolypoly-866f8a.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
This is a good PR but I'm generally opposed to contextual validations. Zod schemas should be self-contained, and schema that rely on params break encapsulation. https://github.com/colinhacks/zod/issues/487#issuecomment-860231900
@colinhacks Ok, I'm not sure of the benefits of keeping shema self-contained no mater what as for certain use cases it would lead into generating the schema in the data validation process. Which is, I think, a bad pattern as it would cause performance issues as you would re-declare a new schema object each time you want to perform a validation losing all the benefits of declaring a reusable self-contained schema. I think it's a trade off between strict encapsulation and performance and even if I won't encourage the pattern I think it's not the role of the library to make this choice for the users. But a warning about encapsulation breaking of this pattern could be nice in the the documentation of the functionality.
I'm closing this PR after @colinhacks arguments and example of workaround mentioned in https://github.com/colinhacks/zod/issues/487#issuecomment-860231900
I'm not 100% sure about the argument of strict encapsulation but I understand it and acknowledge its relevance. I would also argu that strict typings for that functionnality would be a big work that make this PR not mature enough for merge.
Feel free to take back this code if you have interest on it and want to go further on this subject.