Replies: 1 comment
|
yes, unions and pipes are exactly the right tool. The pattern is: the new schema as-is, const NewCard = z.object({ id: z.string(), can: z.string() });
const OldCard = z.object({ iccsn: z.string(), cardAccessNumber: z.string() });
const Card = NewCard.or(
OldCard.transform(({ iccsn, cardAccessNumber }) => ({
id: iccsn,
can: cardAccessNumber,
})).pipe(NewCard),
);
// z.infer<typeof Card> is the new shape, old input is migrated on parseThe I ran into this often enough that I packaged the pattern into a small utility, zod-funnel: you declare the canonical schema once and attach each legacy shape with a type-checked mapper ( |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
My server currently sends an array of old structured data and my client would like to work with new structured data already so when the server switches to new data the client is already ready and can handle it.
During the transitioning period the client is able to handle both old and new data.
I am currently doing this, but it lacks strong typing of
I am transforming into the new data schema, however the new data schema is not strictly defined. I'd like to defined a proper zod schema for new data too and then have the
parsefunction to be able to detect if the input data is of the old format (and will be transformed) or is already in the new format and will just be parsed & checked.Is this possible with maybe unions and pipes?
All reactions