Feature: Conditional Validation Similar to yup.when()

[ckifer]

Similar to this Yup issue: jquense/yup#176 and creating a new issue out of #61.

Many users of zod would like to do conditional requirement or validation of fields based on either fields passed as context to zod, or based off of the value of another schema property. This is common to do in form validations.

The closed issue #61 addresses how to do conditional validation with superRefine. This works well enough in small cases, but many folks have large complex schemas and we would like to keep the existing validation on an object i.e. not have to make the entire object partial in order for conditional requirement to work.

This issue stems from the reaction to my comment #61 (comment)

Pasting from the comment as my case is the same:
I have large schema that needs to require one or another field. A nested partial Zod object with superRefine works for this.

What I want to be able to do however, is to do conditional requirement on 1 or 2 fields without making the entire object partial and while having access to all of the fields in the object.

Ex:
I have a required enum that has two values: "ValueA" and "ValueB"

Upon "ValueA" then someOtherFieldA is required. Upon "ValueB" then someOtherFieldB is required.

There are also other required fields within the schema that should remain required without explicitly checking them in something like superRefine.

The reason I chose zod over yup was TypeScript support, but in yup's beta versions TS support has improved a lot. Not having a functionality like this is a big blocker for me wanting to keep using zod. Thanks!

[snax4a]

This is currently the only problem I have with zod - I have to do conditional field validation in superRefine which is not the problem but then if I want to use that schema in other places with extend() or merge() the problem starts.

I think that something like yup.when() is the only missing part in this schema validation library.

[andrew-sol]

Another possible solution for this issue is Joi's xor() method. Would look like this:

const schema = z.object({
  field1: z.string(),
  field2: z.number(),
}).xor(['field1', 'field2']); // only one of these fields can be present/non-nullish

But when() would be more universal.

Some other possible solutions from different libraries:

• Laravel has rules required_with:another_field, required_without:another_field, and required_if:another_field,value.
• ClassValidator has @ValidateIf((object) => !object.someField)

[413n]

+1

[ckifer]

@colinhacks almost at 90 +1s here. Is something like this even possible in zod? I know you have mentioned elsewhere that it isn't trivial. Anything that you can comment on that might give us an idea if it could even be a feature in the future?

[deniskabana]

I'm joining this thread to provide more requirements than just requiring a if b.

My use case is that I have an optional startDate and endDate that need to create a valid date range (if provided), but can both remain null. If either is filled, the other becomes required and startDate needs to be a date before endDate.

I have achieved this in Yup thanks to when, inside which I also use a custom test. Very verbose, but it is possible.

[nicoabie]

@deniskabana can you provide a code snippet and how you'll like it to be ideally?

[deniskabana]

I wrote a bit of untested code using Yup for you since I have never worked with Zod before. I wanted to dive in deep today - I read the official website's docs and a few tutorials, took a look at the APIs and then I started googling for my exact use-case.

  Yup.date()
    .when(["startDate", "endDate"], ([startDate, endDate]: [Date, Date], schema) => {
      if (!startDate && !endDate) return schema;
      if (startDate && !endDate) return schema.required(errors.validation.dateRange.required);
      if (!startDate && endDate) return schema.required(errors.validation.dateRange.required);

      return schema.required().test("date-range-test", errors.validation.dateRange.startBeforeEnd, () => {
        // Check if both are dates object
        if (!("getMonth" in startDate) || !("getMonth" in endDate)) return false;

        const monthFrom = startDate.getMonth();
        const monthTo = endDate.getMonth();
        if (monthFrom < monthTo) return true;
        if (monthFrom > monthTo) return false;
        return startDate.getDate() < endDate.getDate();
      });
    });

This is verbose, has no type checkings, but it works (I suppose - I haven't tested this specific snippet).

[ckifer]

@deniskabana definitely a valid case imo. Ideally we would have access to the rest of the schema, access to some sort of context external to the schema (if passed), and would be able to change the validation on more than just one field at a time while maintaining the validations that have been untouched. The biggest problem with superRefine in Zod is that you have to make the object partial and re-add every existing validation (essentially making the original validations useless).

[colinhacks]

This isn't going to happen in Zod, sorry folks. I find the .when API very unaesthetic and it adds nothing in terms of type safety. There's no other scenario where Zod has you specify object keys with strings; it's hacky and looks bad. It breaks locality. The reason Zod is easy to learn is because it's clean and compositional. There's no reason a child schema in a ZodObject should behave differently based on its sibling fields, ever.

without making the entire object partial

This was never necessary, I was just trying to simplify the example code I provided in #61. You need to make the two relevant fields optional then add an appropriate refinement.

const myObject = z
  .object({
    first: z.string().optional(),
    second: z.string().optional(),
  })
  .refine(
    data => !!data.first || !!data.second,
    'Either first or second should be filled in.',
  );

If you want slightly more accurate union typing, declare a base type, create your variants, and union them together.

const baseObject = z.object({
  // whatever
});

const mySchema = baseObject
  .extend({ first: z.string() })
  .or(baseObject.extend({ second: z.string() }))

To solve the case where different fields are required based on an enum key:

z.object({
  key: z.enum(['first', 'second']),
  first: z.string().optional(),
  second: z.string().optional()
}).refine(val => {
  if(val.key === 'first') return !!val.first;
  if(val.key === 'second') return !!val.second;
  return true;
})

There's no scenario I see where a when API improves on this in terms of type safety, readability, or performance.

[deniskabana]

@colinhacks Thank you for your response! I understand your point about Yup's when API being messy. It really is.

But now as I'm working with the date range values as in the example I provided, I don't see how to make a refinement easy and readable, that does the following:

• Start and end dates must both be null or filled
• If filled, start date needs a Date object pointing to a date before the end date
• There are daily opening and closing times for each event (full 7-day week) specified like. I left these out from the previous example, but I feel these might further complicate the use of .refine() here
• Opening and closing times follow rules 1 and 2 - opening and closing for the same day must both be null or filled and opening must be before closing

I can validate this easily on the server with custom logic. But it would make much more sense UX-wise if this was easier to implement on the frontend as well for immediate user feedback.

[colinhacks]

Thanks for the response @deniskabana. The problem is that these refinements shouldn't live inside the ZodDate instance. They should get attached to the ZodObject schema that contains startDate and endDate. Let me know if I'm still misunderstanding.

const schema = z
    .object({
      startDate: z.date().optional(),
      endDate: z.date().optional(),
      actualDate: z.date(),
    })
    .refine((val) => {
      if (!val.startDate && !val.endDate) return true;
      if (!val.startDate || !val.endDate) return false;
      return val.actualDate >= val.startDate && val.actualDate <= val.endDate;
    });

Note that you actually have typing on startDate and endDate because this approach doesn't try to break locality, unlike the Yup example, in which Yup has no idea what the type should be on those values. Way less verbose and more typesafe. Use superRefine if you want to customize error codes or messages.

You can also define this refinement as a separate function and drop it into multiple schemas.

  const dateRangeValidator = (val: {
    startDate?: Date;
    endDate?: Date;
    actualDate: Date;
  }) => {
    if (!val.startDate && !val.endDate) return true;
    if (!val.startDate || !val.endDate) return false;
    return val.actualDate >= val.startDate && val.actualDate <= val.endDate;
  };
  
  const schema = z
    .object({
      startDate: z.date().optional(),
      endDate: z.date().optional(),
      actualDate: z.date(),
    })
    .refine(dateRangeValidator);

[deniskabana]

@colinhacks Thank you for that response with examples, that really cleared the situation for me!

To further clarify for you and others, Yup does check the date type, so the actual schema for the example I have shown would be Yup.date().required().when(...) but I ended up with 300 lines of code for form validation with Yup. Ouch. After decoupling some of the validations to functions and referencing those, it was still almost 200 lines of code. Hence, I sympathize with your opinion about how unaesthetic the when API is in Yup.

The second example of yours clears this very well. There is no need to use superRefine other than for the error messages. Have a great day!