You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a fairly complex recursive set of types and schemas that require us to define our types before our schemas and use z.ZodType when defining schemas. This is along the lines of this pattern - https://zod.dev/?id=recursive-types
We've noticed that when we define our schemas this way we get type errors when trying to create a discriminated union on these types.
Yeah, unfortunately that won't work as those recursive schemas are types as ZodType, whereas z.discriminatedUnion only accepts object types at the moment. This is one of the fundamental problems I'm aiming to solve with Zod's next major version (coming soon™)
The reason this has come up for us now is that we faced a sudden and dramatic parsing performance issue on a largish dataset after adding one more type to the existing union of six types (not discriminated). I remembered reading at an earlier time that using a regular union vs discriminated could be quite a bit less performant due to the need to test for each during parsing so I tried moving to discriminated and was reminded of why they weren't initially setup like that.
Interestingly as an experiment I annotated the type errors caused by changing to a discriminated union with @ts-ignore and parsing was very fast but it also worked which I wasn't necessarily expecting. I haven't explored why this is ok or whether it's safe to do in the interim yet but it certainly shows the difference in performance.
We have a fairly complex recursive set of types and schemas that require us to define our types before our schemas and use z.ZodType when defining schemas. This is along the lines of this pattern - https://zod.dev/?id=recursive-types
We've noticed that when we define our schemas this way we get type errors when trying to create a discriminated union on these types.
A simple reproduction
This compiles fine.
This won't compile and results in the ts error following
Is there a supported way to achieve discriminated unions on schemas defined in this way?
The text was updated successfully, but these errors were encountered: