Return data and errors

[danvoyce]

I'm finally getting around to taking Zod for a spin. I'm using safeParse so things don't blow up, however it would be great if there was a way that it would still return the parsed data as well as any errors it finds.

My use case:

I'm fetching a large amount of data and would like to display it all, even if there are a few errors. I can do this by using things like z.coerce and .nullable(), and I believe I can use transform (however I'm trying to be wary of performance).

Ultimately i'd like to be informed if there are any errors so I can do something about them, but I don't want to prevent the user from using the app, as it's very likely they wouldn't notice anyway.

If safeParse could return something like this it would be awesome:

{
   data: ParsedData,
   error: Errors[]
   success: Boolean
}

[JacobWeisenburger]

Perhaps this would help you:
https://github.com/JacobWeisenburger/zod_utilz#partialsafeparse

If you found my answer satisfactory, please consider supporting me. Even a small amount is greatly appreciated. Thanks friend! 🙏
https://github.com/sponsors/JacobWeisenburger

[apatrida]

It isn't clear this works on nested objects, and only on top-level errors instead. can you clarify @JacobWeisenburger? Also the typing doesn't allow non-object root nodes in the schema (unions, arrays, optional, ...)

[apatrida]

also, this appears to pull data from input, not applying defaults, transforms, preprocess or any other zod effects.

    const validInput = omit( inputObj, keysWithInvalidData )
    const invalidData = pick( inputObj, keysWithInvalidData ) as Partial<z.infer<Schema>>

given a schema:

const testSchema: z.AnyZodObject = z.object({
  a: z.object({
    b: z.object({
      c: z.string(),
      d: z.boolean().nullish().default(true),
    }),
  }),
});

this input will succeed in zod

{ a: { b: { c: 'ccc' }, a2: { b2: 'foo' } } }

and return

{"a":{"b":{"c":"ccc","d":true}}}

which partialSafeParse also returns as it passes through zod results.

but with this input that errors only on the a.b.c field:

{ a: { b: { c: 1 }, a2: { b2: 'foo' } } }

will return

validData: {}
invalidData: {"a":{"b":{"c":1},"a2":{"b2":"foo"}}}}

based on the zod error:

[{"code":"invalid_type","expected":"string","received":"number","path":["a","b","c"],"message":"Expected string, received number"}

as it flattens the errors to just

{"a":["Expected string, received number"]}

and then removes 'a' from valid, while including it in invalid. BUT, it takes these from the raw input data, nothing from the processing of zod, and is using the types of the schema to decide the fields, but the inferred type. It should actually be validData: z.output<schema> (coming from zod default, preprocess, transform, pipes, ...) and invalidData: z.input<schema> (coming from source input data)

This is incomplete and does not list any caveats in the page, so can mislead/disappoint people.

[danvoyce]

Thank you @JacobWeisenburger, this is exactly what I need!

[dalmo3]

Same here. First time using zod and it's weird this isn't native functionality. Here's my workaround:

const validateObj = (obj) => {
    const parsed = schema.safeParse(obj);

    if (parsed.success) {
      return parsed.data;
    } else {
      const fieldErrors = parsed.error.flatten().fieldErrors;

      for (const field in fieldErrors) {
        delete obj[field];
      }
      return obj;
    }
  }

[danvoyce]

Coming back here after some time with another scenario where I don't want to throw an error and prefer to show the data I have.

I'm working around this like so:

      const data = await res.json();

      const parsedResponse = Schema.safeParse(data);

      if (!parsedResponse.success) {
        console.error(parsedResponse.error);
        return data as z.infer<typeof Schema>;
      } else {
        return parsedResponse.data;
      }

Not horrific but doesn't feel great either.

https://github.com/JacobWeisenburger/zod_utilz#partialsafeparse would be great, however it's doesn't work in the browser nor does it seem to be actively maintained.

Is this something that could be considered for the core library? I'd be happy to contribute if so (cc @colinhacks)?

[apatrida]

partialSafeParse has implementation flaws as of this date, see above.

[finci-square]

+1 for this.... I essentially want to use Zod to check the inputs (api calls) to my application and report errors (to sentry/bugsnag/etc) however I don't want like e.g. one individual field missing somewhere far down a object graph to blow up the entire application when it would really only affect one small isolated part of it

[JacobWeisenburger]

I have updated zod_utilz to work in the browser. So give this a try: https://github.com/JacobWeisenburger/zod_utilz#partialsafeparse

[arielweinberger]

I find it strange that this is not a part of zod.

[MohammedFaragallah]

@JacobWeisenburger any plans to support the same scenario for z.record ?

[comatory]

I ended up not using zod_utils. I did not want to wrangle the type system. The function partialSafeParse did not like my schema because it contained .refine method. I'd rather avoid using these utils as it's another dependency and I'm unsure whether it's battle tested.

This is not a dig against zod_utils author, I think it's great to solve a pain. I'd just rather something that's more integrated.

I wish that we could access the original values via

a/ a method on the result of safeParse, e.g. mySchema.safeParse({ ... })._unsafeRaw() or perhaps be present on the errors fields as originalValue field.

---

My solution for now is to mirror the schema and using .coerce. It's not great but it allows me to pass original values back to the form with better DX.