Replies: 2 comments
-
Hi @tremby, I generally recommend keeping schemas and relative transformations together unless there's a specific need to make some kind of composition with schema. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I would say you're using it a good way. I hate when people add too much transformation logic to the schemas. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have a complex data input which comes as a series of records, each of which has a nested series of a different kind of records.
I don't have actual documentation for that input format, so I want to have warnings pop up if the input doesn't match the expected format, in case there are forms of data I haven't seen before and handled.
I then need to do some lookups, manipulation, reorganizing, etc, and transform it all into an output which looks quite different. The output is two separate maps of somewhat-flat records.
I'm a beginner with Zod.
What I've done is modelled all the input data is closely as I can with Zod types, and then I've also modelled the output format I'm aiming to produce.
My transformation logic all happens separately, outside of Zod, though I'm using the inferred types Zod hands me to help build the various pieces of logic.
So I import my data and ask Zod to parse it against the input format. If there are errors these are emitted. If it succeeds, I move on, and I now have strongly typed input data. I run all my transformation logic and gradually build up my output objects. I then ask Zod to parse that against the output format, and once again if there are errors they're emitted. Otherwise the transformation was successful, and I output it.
Is that a "correct" way to use Zod?
Or am I shooting myself in the foot by not adding transformation logic right in to the Zod schema I've built? If I understand the docs properly, "parsing" and "transforming" are essentially one and the same in Zod, and if I went this route instead by passing logic into
transform
methods, it would be done as part of my call to theparse
method. But then I wouldn't be getting inferred types for both the input and the output types, only for the output. Is that right?I haven't sat down and tried yet, but my input and output data formats are so different from each other that I'm finding it hard to imagine being able to put all my transformation logic neatly into the schema. Is there a certain level of complexity, or of magnitude of difference between the input and output formats, at which using
.transform()
wouldn't make sense any more?Beta Was this translation helpful? Give feedback.
All reactions