Tips on implementing zod schema types with remapped fields using the toZod method

Question

Tips on implementing zod schema types with remapped fields using the toZod method

I'm currently working on mapping a schema key to a different name in my database

interface Country {
        isoCode: string,
        nameEn: string,
        nameDe: string,
        phone: string,
        bla: string
}

const CountryJson = {
        isoCode: 'DE',
        nameEn: 'Germany',
        nameDe: 'Deutschland',
        phone: '+49',
        blubb: 'test123'
}

const testZodObj: toZod<Country> = z.object({
        isoCode: z.string(),
        nameEn: z.string(),
        nameDe: z.string(),
        phone: z.string(),
        blubb: z.string(),
}).transform((item)=>{
        const {blubb: bla, ...rest} = item
        return {
                ...rest,
                bla
        }
})

type countryArray = z.infer<typeof testZodObj>

function print(): countryArray{
        return testZodObj.parse(CountryJson)
}

const out = print()
console.log(out)

However, the transform function returns a ZodType, causing testZodObj to now expect a ZodEffects. Do you have any suggestions on how I could make the key names match the interface?

blubb is the value retrieved from the API and bla is the value I want to store it as.

typescript zod

Answer 1

Answer №1

To simplify the problem statement somewhat, let's consider having the following types for both remote and local data:

interface ILocal {
  a: number;
}

interface IRemote {
  b: number;
}

When parsing, you anticipate the field b retrieved from the API to be placed under a new key: a. This can be easily accomplished by defining an explicit type transformation as shown below:

import { z } from 'zod';
const schema: z.ZodType<ILocal, z.ZodTypeDef, IRemote> = z.object({
  b: z.number(),
}).transform(({ b }) => ({ a: b }));

console.log(schema.parse({ b: 11 }).a); // => 11

An important aspect here is ensuring that the input type differs from the output type explicitly. While z.ZodType usually requires specifying only the output type, in cases where key remapping is needed, the third parameter should be provided.

The result of the .transform(...) operation will still yield a ZodEffect, but it will align with the explicit ZodType.

If you decide to eliminate the ILocal interface and use z.infer instead:

const schema = z.object({
  b: z.number(),
}).transform(({ b }) => ({ a: b }));
type Local = z.infer<typeof schema>;

Local will be inferred to be similar to ILocal.

Delving into opinion territory—please note this is separate from the solution provided, but could be relevant

After some additional research regarding any missing context, I encountered the toZod library which appears to be causing complications. Personally, I find it unclear why one would opt for that library when similar outcomes can be achieved using the fundamental zod library described above. By specifying

z.ZodType<ILocal, z.ZodTypeDef, IRemote>

as a clear type definition, adherence to the zod schema on the right-hand side is enforced. Any deviation in the schema output will trigger a type error without necessitating toZod.

Here's a demonstration tailored to your specific scenario:

// Define this to prevent redundancy
interface IBaseCountry {
  isoCode: string;
  nameEn: string;
  nameDe: string;
  phone: string;
}
interface Country extends IBaseCountry {
  bla: string;
}
interface RemoteCountry extends IBaseCountry {
  blubb: string;
}

const testZodObj: z.ZodType<Country, z.ZodTypeDef, RemoteCountry> = z.object({
  // Insert your code here
});

Answer 2

To simplify the problem statement somewhat, let's consider having the following types for both remote and local data:

interface ILocal {
  a: number;
}

interface IRemote {
  b: number;
}

When parsing, you anticipate the field b retrieved from the API to be placed under a new key: a. This can be easily accomplished by defining an explicit type transformation as shown below:

import { z } from 'zod';
const schema: z.ZodType<ILocal, z.ZodTypeDef, IRemote> = z.object({
  b: z.number(),
}).transform(({ b }) => ({ a: b }));

console.log(schema.parse({ b: 11 }).a); // => 11

An important aspect here is ensuring that the input type differs from the output type explicitly. While z.ZodType usually requires specifying only the output type, in cases where key remapping is needed, the third parameter should be provided.

The result of the .transform(...) operation will still yield a ZodEffect, but it will align with the explicit ZodType.

If you decide to eliminate the ILocal interface and use z.infer instead:

const schema = z.object({
  b: z.number(),
}).transform(({ b }) => ({ a: b }));
type Local = z.infer<typeof schema>;

Local will be inferred to be similar to ILocal.

Delving into opinion territory—please note this is separate from the solution provided, but could be relevant

After some additional research regarding any missing context, I encountered the toZod library which appears to be causing complications. Personally, I find it unclear why one would opt for that library when similar outcomes can be achieved using the fundamental zod library described above. By specifying

z.ZodType<ILocal, z.ZodTypeDef, IRemote>

as a clear type definition, adherence to the zod schema on the right-hand side is enforced. Any deviation in the schema output will trigger a type error without necessitating toZod.

Here's a demonstration tailored to your specific scenario:

// Define this to prevent redundancy
interface IBaseCountry {
  isoCode: string;
  nameEn: string;
  nameDe: string;
  phone: string;
}
interface Country extends IBaseCountry {
  bla: string;
}
interface RemoteCountry extends IBaseCountry {
  blubb: string;
}

const testZodObj: z.ZodType<Country, z.ZodTypeDef, RemoteCountry> = z.object({
  // Insert your code here
});

Tips on implementing zod schema types with remapped fields using the toZod method

Answer №1

Similar questions

The function Sync in the cp method of fs.default is not a valid function

Developing a custom React hook that utilizes the useContext functions

The upcoming router is not compatible with the NextPage type

What is the best way to close ngx-simple-modal in angular7 when clicking outside of the modal component?

Automatic completion of absolute paths in VS Code with the ability to click and view definitions through the configuration file js/tsconfig.json

Each time the Angular Service is called, it undergoes a reset process

Retrieve a static property from a specific type

What is the best way to define a function agreement in Typescript?

Improving the App() function in React and Typescipt

What is the issue with this asynchronous function?

Derive a data type from a parameter passed to a function defined within an interface

Compilation of various Typescript files into a single, encapsulated JavaScript bundle

Strange interaction observed when working with Record<string, unknown> compared to Record<string, any>

Unable to get md-virtual-repeat to work within md-select?

Encountering a 404 error while trying to deploy a React app on Verc

The Angular CLI suddenly decided to stop providing me with useful lines (without sourcemaps) in the browser console, but interestingly the terminal continues

Exploring the functionality of className using materialUI

Angular2 encounters an error when processing a custom HTTP request

Unable to reference the namespace 'ThemeDefinition' as a valid type within Vuetify

Adding an object with a composite key to an IndexedDB object store is not permitted as the key already exists within the store. This limitation occurs when attempting to add an entry