You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would be beneficial if zod provided a schema method that essentially strips all transformations found in this schema, even the nested ones (eg: noTransform and deepNoTransform). The benefits of this would be that maintaining two separate schemas with the same shape, with the only difference being transformations, wouldn't be necessary.
Example:
constfoo=z.object({name: z.string()}).transform((data)=>{data.name=data.name.toUpperCase();returndata;});constbar=z.object({something: z.string(),foo: foo,}).transform({
data.something=data.something.toLowerCase();returndata;});constdata={something: "ALL UPPER"foo: {name: "all lower"}};bar.parse(data)// == would apply transformationsbar.noTransform.parse(data)// == would only ignore the transformation of `bar`, but not `foo`bar.deepNoTransform.parse(data)// == would ignore all transformations
Currently, I have a situation where transformations are hydrating some objects, which works well in application logic, but not for serving parsed data as JSON. To avoid this, I have to maintain two schemas, one with, on without transformations. These schemas can be deeply nested and it's very labor intensive to keep them in sync.
If there's currently a way to achieve what I demonstrated, I would greatly appreciate the advice, otherwise I think adding this to zod's API would be awesome.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I think it would be beneficial if zod provided a schema method that essentially strips all transformations found in this schema, even the nested ones (eg: noTransform and deepNoTransform). The benefits of this would be that maintaining two separate schemas with the same shape, with the only difference being transformations, wouldn't be necessary.
Example:
Currently, I have a situation where transformations are hydrating some objects, which works well in application logic, but not for serving parsed data as JSON. To avoid this, I have to maintain two schemas, one with, on without transformations. These schemas can be deeply nested and it's very labor intensive to keep them in sync.
If there's currently a way to achieve what I demonstrated, I would greatly appreciate the advice, otherwise I think adding this to zod's API would be awesome.
Beta Was this translation helpful? Give feedback.
All reactions