Contextual validations

[chrbala]

I'm looking for a way to validate in different ways in different contexts. For example, take a complex object on the client (browser) with foreign-key fields (IDs) that map to other objects on the backend. The client has a mechanism for retrieving these IDs and naturally trusts them. The client also may not have a reasonable mechanism for validating them. On the server, we don't trust these to be valid IDs by default. We need to ensure that they map to real objects.

How would we share most of the schema, but have slightly differing validations in different contexts?

From a high level, I'm thinking of a context object that can be passed down and used in the validators similar to how a lot of GraphQL server implementations work.

[colinhacks]

Not a fan of context objects or other patterns that break locality. This is also why I'm opposed to something akin to Yup's meta properties. If you need additional properties I think best approach is usually to build a tool/layer on top of Zod.

You allude to this use case in another issue, and I mentioned there that I'm working on a schema .patch method for modifying a schema (perhaps deeply). Would that address all your use cases?

To answer your question in the general sense ("How would we share most of the schema, but have slightly differing validations in different contexts?") I think the best way is lerna or yarn workspaces. I know that's not what you meant though 😛 Are you using one of those? If you are I'd love to see a writeup of that. How to share schemas across client & server is a big blind spot of the docs currently.

[chrbala]

It seems to me that patching could get out of hand pretty quickly. Like if you have something like object -> union -> object -> string with custom validations, how would you readily do a deep patch to target the string but not on other variants in the union? It seems like that would get pretty complex both on the implementation side, and might be hard to follow on the application side. This is why I'm wondering if my suggestion in #85 (comment) is the right approach.

What kind of tool do you see on top of zod? Are you envisioning a library that define the structure and create a zod schema based on that, or would it be more application logic? I guess it's not clear if zod should be considered a low-level primitive, or if it's something that applications would more commonly depend on directly. If it is a low-level primitive, guidance on the best ways to create tools on top of it would be helpful.

What I mean by "different contexts" is less about how or where the schema is used, but on a conceptual level. There may be validations that can not or should not be run in some circumstances. A couple examples:

• Validations that only the server can do because of access to resources.
• Validations with a CPU performance hit, so the validations need to be debounced, run on field blur, form submission, etc so as to not drop frames
• Validations that call out to the backend (assuming Asynchronous validations #87 is done) need to be debounced, run on field blur, form submission, etc so as to preserve server resources/bandwidth/etc

So for a full-stack example, there could be 3+ schemas in operation with lots of shared logic:

• API validations
• Validations that happen frequently on user input
• Validations that happen infrequently on the client

[colinhacks]

Doing some housekeeping and not sure how to act on this issue

[chrbala]

Okay to just leave this one hanging for a while? I think things may get clearer once more work has been done on a full-stack example for #86. I've been working on that one for some time - it's been going back and forth between that and your work on #100 which my implementation of #86 is dependent on.

[colinhacks]

Sorry, accidental close 😬

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jonlambert]

Was there ever a solution for this? We're struggling with this problem at the moment. Currently getting around it by reading from a store in a refine() call, but that feels super dirty.