-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Override safeParse and parse behavior at a given key #3448
Comments
Updating on this - realizing what I want is aversion of safeParse that returns its best attempt at parsing the schema alongside the error. So even if there is a failure in a given subschema I'd still want to return as much data as possible. |
Just making the fields optional and or nullable is not enough? Combined with a .passtrhough should be plenty. |
@m10rten thanks for the response! I'm happy to work with existing apis if they achieve the goal, but as I understand my use case isn't supported (without adding custom transports/logic). I think this down to
As an example - I have some fields that are absolutely essential, and some that are non essential. I want to be warned when non essential fields are not present (or are but not in expected type) but I still want to parse the data in the response type. Putting a trivial example here. If my schema were
And I was parsing two objects, like below
The desired behavior is an error thrown in the first case, while in second I would expect to get {success: false, error: ZodError, data: any}. In case 2 I'd expect "data" to be
Can I achieve this using the library as it is right now? Is it possible (without lots of boilerplate) in large schemas? |
I suppose you could make a |
Thanks for the response! Not sure I understand what you mean by destroys your request. If I understand correctly I don't believe that's what I want; I'd still want to error when "essential data" is not present. Ideally I'd want to be able to parse with a single api (i.e. And to be explicit about my suggestion - it would be an extension, not default. I'd want to add Also, I want to draw a distinction between 2 related but distinct use cases I'd want to support. The labels I'd put on each are
I think a new discussion/issue is warranted for the first item as it's a separate ask. It's also the api I care more about. Can continue discussion for the second item in this thread as it is appropriately named. |
Zod would benefit from some concept of "error levels" and Zod 4 will likely include some concept of a "warning". z.string().min(5, { level: 'warn' }) That said, I don't love the idea of a warning on a type check: z.string({ level: 'warn' }) Because this introduces the possibility to the result of I'd be willing to entertain something like this: .safeParse(data:unknown): { success: true; data: T; } | { success: false; error: ZodError; data: unknown } In this scenario, |
Warning on type check can then be avoided using an union/or. That would be a great feature. |
@colinhacks Thanks for the response! Happy to hear about some related features on the roadmap. Ensuring a match with valid static typing makes sense. Unknown makes sense as a default; alternatives could be not returning the mismatches at all or using This would achieve what I meant by "Return data alongside safeParse failures". Happy to take a look and put together a PR to add this, is there any related active development to consider/places to start? And to address the original title of the issue for anyone coming to this thread in the future - inline overriding of throw/warn behavior is discussed above but conversation here is about returning data alongside safeParse failures. |
@m10rten @colinhacks put together a draft PR as a starting point on a fork of the repo. https://github.com/EllAchE/zod/pull/2/files. Wanted to share for further discussion. Implementation here ^ just types the return result of any safeParse as Alternatively we could get static typing by:
Some other notes:
|
I'm looking to implement a Zod schema that supports "hard" and "soft" type definitions in the same schema with little boilerplate. What I mean by that is combining the behaviors of parse and safeParse in the same schema.
For example, given a schema
If the parsed object doesn't have a string value for
errorIfNotString
I want to throw an error. IfwarnIfNotString
is undefined, number type etc. I want to follow safeParse behavior and return an error message, but not throw. I understand this would be possible right now, I could define two separate schemas and call safeParse for one & parse with the other. However this can get complex for large objects, so I'd prefer an API that is something like the below:The expected behavior would be an override of the called parse method. I.e. if I call parse() on simpleSchema, zod should still not throw an error in the event of mismatch on warnIfNotString. And if I call safeParse zod should still error if errorIfNotString ends up being a mismatch.
Happy to look into this and come back with a PR too, just wanted to get the discussion started!
Some quick things to note:
The text was updated successfully, but these errors were encountered: