Replies: 2 comments
-
One of the most significant issues with top level transformations is that one can transform object into something else: .build({
input: z.object({}).transform(() => []),
}) It's hard to track in runtime (requires to run those transformations), it breaks the types (augmentation of inputs from middlewares) and violates the core concept of the library — always to operate objects, @rottmann |
Beta Was this translation helpful? Give feedback.
0 replies
-
That's what I thought too. I use a now a manual transform solution, so it breaks not the types and keeps openapi-docs: import camelize from 'camelize-ts'
import snakify from 'snakify-ts'
//...
export const Input = ... // zod schema
export type Input = Camelize<z.infer<typeof Input>>
export const Output = ... // zod schema
export type Output = Camelize<z.infer<typeof Output>>
//...
handler: async (args) => {
const input = camelize(args.input)
const result = await doSomethingWithCamalcasedData(input)
return snakify(result)
}, |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
A REST-API uses normally underscores in keys for input and output data structures.
In the source code, I would like to work with camelCase params.
This post describes it really good: colinhacks/zod#2240 (comment)
Currently, top-level transforms are not allowed.
Input is
Work in src should be
Output should be
The transform should be set with EndpointsFactory, so everybody could transform it into personal style.
Don't know if this is too complicated to implement, or the Typing-Overhead would be too big.
What did you think?
Beta Was this translation helpful? Give feedback.
All reactions