Theo's Typesafe Cult•2y ago

3rd party Zod validation

Has anyone ever validated 3rd party requests with Zod? Running into an issue where one property might be different down the line since we don't control this api. If I use safeParse it'll give me an error object but no validated data. Is there a way to retrieve the validated data sans the property that errored out? Maybe I'm overthinking this?

Solution:

you can also do like ```ts const parse = someSchema.safeParse(apiResponse); if (!parse.success) {...

Jump to solution

16 Replies

cje•2y ago

if you only need some keys you can make a schema for those and .passthrough everything else https://github.com/colinhacks/zod#passthrough

GitHub

GitHub - colinhacks/zod: TypeScript-first schema validation with st...

TypeScript-first schema validation with static type inference - GitHub - colinhacks/zod: TypeScript-first schema validation with static type inference

ZeroOP•2y ago

Yeah so we have a schema for everything we need from that 3rd party. Lets say propA expects a string but we get number from the 3rd party - will passthrough strip it out and let us continue as usual?

cje•2y ago

if propA is on the schema, then no

ZeroOP•2y ago

Yeah that's the issue

cje•2y ago

you could coerce

ZeroOP•2y ago

The possibility that propA might return something we didn't actually expect Because the other team doesn't update us Pretty sad

cje•2y ago

well thats the entire point of zod its meant to fail if the data doesn't match the schema

ZeroOP•2y ago

Yeah that's understandable. It was an ask by the team to continue as usual with the properties which were okay. Weird. I'll try to convince them that if this happens we should be fixing the issue Shrug

thanks! @cje

cje•2y ago

for your specific example you can do something like

import z from "zod";

const fooSchema = z.object({
    bar: z.coerce.string(),
})

const foo = fooSchema.parse({ bar: 123 }); // passes

import z from "zod";

const fooSchema = z.object({
    bar: z.coerce.string(),
})

const foo = fooSchema.parse({ bar: 123 }); // passes

you could parse partial things against partial schema etc but ultimately the point of validation is to validate

ZeroOP•2y ago

Yeah. It was kind of a weird discussion we had. Initially I believed it had to do with extra properties in the response of the 3rd party API. And I know that Zod strips the extra properties we don't care about But it turns out they're trying to make the function continue despite the validation error

cje•2y ago

"continue with the properties that are ok"... means don't do anything with the properties that aren't ok? or just let those things into the application and pray nothing breaks? dont validate then lol

ZeroOP•2y ago

the latter

Solution

cje•2y ago

you can also do like

const parse = someSchema.safeParse(apiResponse);
if (!parse.success) {
    notifySlackChannel("api response is fucked up", parse.error);
}
// continue with `apiResponse` and pray nothing breaks

const parse = someSchema.safeParse(apiResponse);
if (!parse.success) {
    notifySlackChannel("api response is fucked up", parse.error);
}
// continue with `apiResponse` and pray nothing breaks

ZeroOP•2y ago

I love this actually

cje•2y ago

i set this up in a few places at work we deal with a TON of external APIs that will just change shit without telling us so its good to know as soon as something changes or even sometimes the schema is based on expectations of the api that aren't completely true can easily happen with a complex api so it becomes an edge case detector

ZeroOP•2y ago

Yeah this isn't a bad idea actually I don't have anything for a slack channel but that's also not a bad idea as well Thanks for the suggestion

Gaming

Programming

3rd party Zod validation