Open muametgrooby opened 1 year ago
Most typescript built-ins are implemented as methods, which lets us provide cleaner autocompletion.
I don't think we'll implement extract
. It's very difficult to determine at runtime if one Zod schema represents a type that assignable to another Zod schema. It would require re-implementing a non-trivial chunk of the TypeScript compiler.
I really needed a way to extract a type, and I was happy to find that the following suits my needs
const eventSchema = z.union([
z.object({
type: z.literal('success'),
data: z.any(),
}),
z.object({
type: z.literal('error'),
message: z.string(),
}),
]);
eventSchema.and(z.object({ type: z.literal('error') })); // result: z.object({ type: z.literal('error'), message: z.string() });
@colinhacks Maybe .extract
can be an alias to the example above?
Ah smart! That would indeed be logically equivalent here. In the general case Extract<A, B>
isn't equivalent to A & B
though. Zod could potentially implement a ZodExtract
subclass that would use the same parsing logic as ZodIntersection
internally, but it would be a performance footgun. In your example, Zod will still naively parse the input using the entire union schema, plus the schema you passed into .and()
, then merge together the outputs.
Since zod tries to resemble TypeScripts API and its types, I think it would be awesome if some built in utility typescript functions were available in zod too
Here are a few examples how these generic functions would work