Mark fields as type-identifiers

[rsinohara]

Would it make sense to set some fields as "type marker", meaning if those fields fail validation, no other fields need to be checked for that schema, moving on to the first parent union member?

We could then mark some fields, and avoid many errors that are due to checking the wrong types (and, when that happens, we end up looking for those fields anyway to see which type was the intended one).

Something like this:

{
   type: z.string().brand()
}

[colinhacks]

This would likely take the form of a higher-level z.discriminatedUnion construct. Something like:

z.discriminatedUnion([
  z.object({ kind: z.literal('a'), data1: z.string() }),
  z.object({ kind: z.literal('b'), data2: z.string() }),
  z.object({ kind: z.literal('c'), data3: z.string() }),
], 'kind')

With some static validation to make sure 'kind' is a key shared by all elements of the array. Though I'm making this up off the cuff, open to other proposals by @scotttrinh or others.

[rsinohara]

I have a few questions still. You can't point me to the right place to learn about discriminated unions, or a better place to discuss. We could also have a chat if you prefer.

But here it goes anyway.

The way I see it, this discrimination is more a property of a field, not the union itself (since TS discrimination is not a factor). Something like "if this field fails validation, don't bother with checking and outputting errors for other fields" (also probably checking those fields before others).
Meaning two schemas inside an union could have distinct discriminating fields (or, easily, sets of). .kind() on those fields only sets a flag with this behavior.

To me, the concept of kind seem like something that belongs to a schema, independently of it being part of an union or not.

PS: I am probably missing a lot of history/experience with zod, not so much challenging but trying to understand ;)

[scotttrinh]

Something like "if this field fails validation, don't bother with checking and outputting errors for other fields" (also probably checking those fields before others).

This makes sense and as you've said, this is somewhat orthogonal to discriminating between different members of a union. If I understand correctly, this is more of a performance optimization since it's saying "check this/these field(s) first, and if they fail, don't continue checking". I can definitely see a use case for this, but I'm concerned that it would lead to confusion about how and when to use a feature like this. I think the order of the keys in an object definition determines the order in which we check the values, so maybe having another parsing mode that fails on the first error rather than returning all errors might satisfy this use case and allow the schema consumer to determine the behavior that they desire?

Something like —

someSchema.failFastParse(input);

[rsinohara]

I think that will also work.

My angle is more of error output, but of course in this case it goes hand in hand. What you just proposed would work too for me.

[rsinohara]

@scotttrinh Do you think it's something I should try implementing?

[scotttrinh]

I would love to get some input from other maintainers, too. I wonder if we would want/need to implement a throwing and safe version, or maybe pass options to parse/safeParse instead of having a separate method? @colinhacks any thoughts on this?