11 Replies
Can we maybe discuss over a concrete implementation? You can use this fork of the Zod sandbox on Codesandbox: https://codesandbox.io/p/sandbox/prod-https-pjskkj?file=/src/index.ts:1,1
prod-https-pjskkj
CodeSandbox is an online editor tailored for web applications.
I'd like to see some real input data and the desired output data. I think we can maybe get to a schema that works at runtime, even if the type system is unable to encode the logic itself.
Basically
superRefine and transform can do anything so there isn't anything at runtime we can't achieve, but the types are limited to what can be easily expressed in objects, unions, and intersections.
although even the type thing can be overcome with some assertions.I will take a look later, currently in meeting
oh and I noticed also
z.discriminatedUnion isn't working on schema's that have .transform being called on them. I suspect typing might be too strict.
Basically superRefine and transform can do anything so there isn't anything at runtime we can't achieve, but the types are limited to what can be easily expressed in objects, unions, and intersections.Yeah I'm fully aware, just not fan of doing it in
.transform or .superRefineYep, that's a limitation of how we implemented
discriminatedUnion to ensure you don't accidentally pass a non-ZodObject.Yeah is there an ability to type it slightly different?
There are several proposals to improve
ZodDiscriminatedUnion, but nothing that has been agreed on. Colin wants a fundamentally more flexible approach.
FWIW, from the perspective of the types that are inferred, there is no difference between ZodDiscriminatedUnion and ZodUnion, they both produce values of X | Y | Z, but at runtime, ZodDiscriminatedUnion only parses one schema based on the discriminant.
It's strictly a runtime optimization (and produces more helpful errors since we know the intent based on the discriminant)mYeah that's why I want it 🙂
Otherwise my error messages truely look like crap
Colin proposed a solution called
switch that allows arbitrary schema selection based on some callback, but that's impossible to introspect, so we've been a little slow to develop that.I would love that actually
as proposed, it would break all of the existing ecosystem libraries that rely on introspection.
Like literally all of this: https://discord.com/channels/893487829802418277/893488038477434881/1129099975893209149
Ehh
Whoops.