Zod schema serialize/deserialize

[valerii15298]

How can I serialise/deserialize zod schema?

So that I can store it in database for example as a string and reuse later when needed.

[JacobWeisenburger]

Can you explain more about your use case? Perhaps a give a code example.

[dabdine]

I had been looking into this to see if it was a possibility and stumbled on this discussion, so let me describe mine:

We're using a SSR-based framework for serving our application, Remix. Remix has loaders and actions, which allow for reads and writes server-side, respectively.

In my particular use case, we have two separate sets of fields (one describing a user, the other describing an organization) that need to submit to a single action URL (the action in Remix). Implementation wise, that looks like two separate Zod objects that we then .merge to create a single object to validate the form.

In some cases we have the user portion, but not the organization portion. When we have the user portion, we don't want to ask/revalidate that information (long story short, it causes an issue with our form validator, remix-validated-form). Being able to make the user portion optional by checking the value of some variable (for example, look up the user in the database and if the user is defined, make the user portion optional) would be nice to define, but that happens server-side. Thus, being able to conditionally construct a zod definition server side, then serialize it to the client (client component) would be helpful.

However, there are workarounds. The easiest workaround is to simply compute this with the non-server side components by sending the user portion (in our case) to the client and performing the calculation there.

In our case, we wouldn't need a database to store the schema in (in fact, we use json schema for that because we have golang in our stack, but I admit Zod is much nicer to deal with).

[sp88011]

Another use case is when you host a form builder (and the eventual form that is built with it). Say you want to allow users who build forms on your site to apply different logic to how the submitted data is transformed.

Storing everything (validation, error-messages, transformation) in a single zod object is elegant, but because it's user-generated it needs to be saved in a DB.

[valerii15298]

@sp88011 yeah, I have exactly the same use case. For now I just decided to store zod schema as raw code string and then use JavaScript eval function

[sp88011]

@valerii15298 I'm curious how you do that.. any chance you can share some snippets? Particularly, how do you turn the Zod object (that presumably was user-generated) into a string that you can later use eval() on?

[valerii15298]

const schemaString = `
// you can put any helper function or code directly inside the string and use them in your schema

function getZodSchema({z, ctx}) {
  // use ctx for any dynamic data that your schema depends on
  return z.object({
    id: z.string()
  });
}
`;

const schema = Function(
  "...args",
  `${schemaString}; return getZodSchema(...args)`,
)({ z, ctx: {} });

[JacobWeisenburger]

I don't think there is a built in way to serialize/deserialize a schema. However, you could definitely write something that would serialize/deserialize a schema. This would be fairly easy for most basic types (string, number, bool), but it might become difficult for more complex objects, records, or arrays.

[StefanTerdell]

This has come up a few times in json-schema-to-zod, which along with its counterpart probably is the closest you'll get to what you're looking for. There has been a couple of requests for a way to do essentially what you're describing here - turn a JSON schema into a Zod schema at runtime. My stance has always been that it doesn't make much sense to turn a perfectly good JSON schema into a Zod schema due to possibly getting weaker validation caused by translation errors or limitations. For instance, there is no (sane) way to deserialize a preprocess callback, and JSTZ even utilizes superRefine to bridge the gap of Zods missing equivalent of the oneOf-keyword! 🤪 Since type inference wouldn't help you at runtime and you can just use the JSON schema with AJV directly it just doesn't make that much sense to me.

Then again, the request keeps popping up, and as the ecosystem grows it may start to make more sense even with the limitations present.

At some point I'd love to find enough time to split json-schema-to-zod into two modules: one to serialize an actual Zod schema and one to stringify it. In the meantime you could just eval the output though.

[shacthulu]

Would serialization/deserialization at runtime using a file of typescript definitions be a viable option in the current implementation? It's obviously a subset of functionality offered by Zod by nature, but feels like it could cover the large majority of practical use cases with a readable syntax and offer a ton of convenience for existing type files, auto documentation utilities, etc.

[nabilfreeman]

For anybody getting here, consider not using zod, instead implementing https://github.com/ThomasAribart/json-schema-to-ts for types and another library for JSON schema validation

[Gregoor]

I started working on a serialization library for zod that also retains type information. It can be found overe here: https://github.com/commonbaseapp/zodex

It's still a WIP, and there are still some battles with TypeScript I'll have to fight (if there's some wizards reading this, reach out if you want to help), but I'm hoping to stabilize soonish!

[brettz9]

Since not everyone wanting a serialization format is looking to work with JSON, converting to JSON Schema might not be ideal for all uses anyhow (e.g., an IndexedDB schema might wish to indicate a date is being stored rather than a date encoded as a string). Zodex sounds like a great beginning—the likes of which I hope may become blessed so there are not competing formats striving to do the same thing.

[theluk]

Zod, IMO is not made for serializing. If you use it heavily with refinements or processing functions, there is no way to serialize it other than stringifying code. I would suggest to refrain from using this approach.

I would suggest sharing your Zod schemas.

I have the following.

• shared/models/MyZodObject.ts
• app/ComponentUsingMyZodObject.tsx
• server/CodeUsingMyZodObject.tsx

Both app and server tsconfigs and bundlers include the shared into their projects.

if you do not have a mono repo, you might still try using linking for example. Another approach is to publish your models to a private npm.

[brettz9]

imo, refinements are sometimes a sign that Zod could have further built-in improvements (e.g., toStringTag checks), but if #2515 were implemented, there'd at least be a way to serialize those refinements, however non-standardly, so that a deserializer could handle them.

There really is a need for storing schemas specific to JavaScript objects (and in a safe way beyond executable code), and Zod (combined with Zodex) already goes very far to this end.