Zod schema serialize/deserialize #2030
-
|
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. |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 10 replies
-
|
Can you explain more about your use case? Perhaps a give a code example. |
Beta Was this translation helpful? Give feedback.
-
|
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 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). |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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 |
Beta Was this translation helpful? Give feedback.
-
|
@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 |
Beta Was this translation helpful? Give feedback.
-
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: {} }); |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
this has been incredibly useful! I've been storing zod schemas as strings and this really helps |
Beta Was this translation helpful? Give feedback.
-
|
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
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…