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
To clarify, I'm not referring to a new primitive schema like the string().uuid().
I agree that previous requests for things like .meta() or .examples() are out of scope for something like zod. However, I've found very useful satellite libraries that have gotten around this limitation by extending the schema (or leveraging .describe()?). Their existence appears to show there is a need for some way to internally anchor, link and document schemas, and they have found their own workarounds. Without this I will probably also have to leverage .describe(), which I'm not a fan of. You can solve the problem of extensibility by abstracting zod into a higher level function, as suggested here: #273, however this won't provide a persistent anchor point physically inside the schema.
What I would like to request is a minimal field similar to .describe() that provides a unique string identifier to the schema. As an example something like .identifiedBy(...), this will be present in the _def field like the description (the name isn't important if the concept isn't good):
constexampleAnchorField=z.string().identifiedBy('ExampleField')constexampleNormalField=z.string()constexample=z.object({// I will be able to introspect the schema and find its unique field in the _defexampleAnchorField: exampleAnchorField,// This will just become just another string field and I lose scope for documenting and lifecycle purposesexampleNormalField: exampleNormalField}).identifiedBy('Example')
Having this internal anchor point for a schema would be very useful for documenting schemas down their lifecycle if I use them in multiple places or derive from them. I have no issue with separating my metadata and examples into abstracted functions from zod, but it would be a more streamlined approach if I could know who was who at the schema level.
I'm hopeful something like this is more agreeable than a blanket metadata field.
The text was updated successfully, but these errors were encountered:
I agree that previous requests for things like
.meta()
or.examples()
are out of scope for something like zod. However, I've found very useful satellite libraries that have gotten around this limitation by extending the schema (or leveraging.describe()
?). Their existence appears to show there is a need for some way to internally anchor, link and document schemas, and they have found their own workarounds. Without this I will probably also have to leverage.describe()
, which I'm not a fan of. You can solve the problem of extensibility by abstracting zod into a higher level function, as suggested here: #273, however this won't provide a persistent anchor point physically inside the schema.What I would like to request is a minimal field similar to
.describe()
that provides a unique string identifier to the schema. As an example something like.identifiedBy(...)
, this will be present in the _def field like the description (the name isn't important if the concept isn't good):Having this internal anchor point for a schema would be very useful for documenting schemas down their lifecycle if I use them in multiple places or derive from them. I have no issue with separating my metadata and examples into abstracted functions from zod, but it would be a more streamlined approach if I could know who was who at the schema level.
I'm hopeful something like this is more agreeable than a blanket metadata field.
The text was updated successfully, but these errors were encountered: