Pattern for required values that start out empty

[evantrimboli]

Is there a common pattern to handling a value that is required, but starts out as an empty value? For example, say I'm creating a task and it should have an owner. My schema would look like so:

const schema = z.object({
  owner: z.object({
    value: z.string(),
    label: z.string(),
  }),
})

However, there's no user that is selected by default and the field is clearable, so as part of the API it would allow setting null. Obviously I could add nullable, but null should end up raising an error indicating that a value is required. What is the best way to allow null as a value, but validate that the value isn't null? Is using refine the expected case here?

[scotttrinh]

I think you have to decide where you schema boundary is, and maybe some of this depends on your use-case. I would personally approach this as two schemas if you have two different cases: one for the schema that describes the possible range of values of your form state, and one for the schema that describes your application model's runtime constraints. The first case is often not that useful to have a schema for.

Something like:

const schema = z.object({
  author: z.object({
    value: z.string(),
    label: z.string(),
  }),
});

type Schema = z.output<typeof schema>;

interface FormData {
  author: Schema["author"] | null;
}

[evantrimboli]

Thanks for your reply. I agree that the schema for the form state isn't necessarily useful here. My main concern is DRY, since it's a fairly common pattern to start forms out as empty. For every valid schema it would be required to go through and pick out where the optional values are needed. Especially in the case where empty strings are "valid" defaults (typically the case), where-as empty dates, or empty numbers are not, even if they are ultimately required:

const schema = z.object({
  name: z.string(),
  dailyRate: z.number(),
  startDate: z.date(),
  office: z.object({
    value: z.string(),
    label: z.string(),
  }),
})

type Valid = z.infer<typeof schema>
interface FormData extends Pick<Valid, 'name'> {
  dailyRate: Valid['dailyRate'] | null
  startDate: Valid['startDate'] | null
  office: Valid['office'] | null
}

const defaultFormValues: FormData = {
  name: '',
  dailyRate: null,
  startDate: null,
  office: null,
}

Obviously the purpose of this library goes beyond solely form validation, but it seems like a common enough pattern to address in some fashion.

[scotttrinh]

Obviously the purpose of this library goes beyond solely form validation, but it seems like a common enough pattern to address in some fashion.

Yeah, I think this is the key to understanding where Zod fits in here: it's primarily about going from unknown -> T and expressing the runtime constraints of your application's domain. The various ways to get that initial unknown (forms, databases/orms, filesystem, etc) are, in my view, an abstraction "above" what Zod is trying to solve. I do think there is a lot of opportunity for people to build abstractions on top of Zod that help with each of these use cases, and if there is something that Zod can do to make writing such an abstraction easier/better/more-correct, I'm definitely open to helping out with something like that!

[StefanTerdell]

I'm guessing you're leaning towards null to keep a MUI input element or simliar as controlled, otherwise it would seem the new .partialBy() method may fit the bill here (not sure if it's released yet, though??). You could always null coalesce on the value prop of the input element, ie. <TextField value={formData.dailyRate ?? null} />