✅ Input / Output transformation

[rottmann]

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

{
  "parameter_one": "1",
  "paramter_two": "2"
}

Work in src should be

handler ({ input }) => {
  console.log(input.parameterOne)
  console.log(input.parameterTwo)

  return {
    myResult: 4711
  }
}

Output should be

{
  "my_result": 4711
}

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?

[RobinTail]

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

[rottmann]

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)
  },

[RobinTail]

There is some progress on this problem, @rottmann :
#1869

I managed to make it work for the input schema.
However, I anticipate another challenge for the output one — in the documentation generator.

[RobinTail]

The problem with transformations is that their output has no schema.
Therefore it's impossible to build an OpenAPI specification on their output.
The solution could be in piping the transformation into another object schema, similar to colinhacks/zod#2240 (comment)

So that roughly it should look this way:

originalObjectSchema
  .transform( transformer )
  .pipe(
    z.object(
      transformer(originalObjectSchema.shape)
    )
  )

But I'm still struggling to make it work with generic transformers like camelize-ts and snakify-ts.

Moreover, those libraries do deep transformations by default, which is not suitable for transforming the original shape, since it contains schemas in values.

Therefore, I'm leaning towards an explicit approach, an object schema where you can define the keys transformation manually.

[RobinTail]

I managed to do it in a neat way — there is gonna be z.object().remap() method in the distributed zod plugin.
I'm going to begin simpler, with explicitly defined keys mapping, as I said above.
The future plan is to make it partial and to support a key transforming function. But this will be later.

[RobinTail]

@rottmann ,

Would you be interested in testing the feature? Your feedback on that matter would be very useful.

In case you would, please find the documentation and examples here:
https://github.com/RobinTail/express-zod-api/blob/allow-top-level-transformations/README.md#top-level-transformations-and-mapping
And install the version ^20.1.0-beta.1 for your experiments.

[rottmann]

The transform-method with zod is absolutely sufficient for this use case and does the job 👍
Thank you!

[RobinTail]

🚀 20.1.0 published
Thank you for the idea and the feedback, @rottmann