janglad - More of a general question? How do yo...
More of a general question? How do you guys organise your zod schemas?
As my app grows I'm starting to get a lottt of schemas. Some of them are the basic schemas that closely relate to the database, but a lot of them are quite complex due to nested forms and often build on and reference many other schemas.
6 Replies
I organize them the same way as I do everything else: Keep them as close as possible to what uses/owns it.
For schemas validating data that is going to be posted to the backend, I keep the schema next to the post hook, in the same file. The form component can then easily import the post hook and the schema from the same place, and when reading the code it's clear that "this is the shape of the data that this post endpoint expects"
yeah I am thinking of moving to something more like that too
I currently keep almost all of em in lib/validation
but my worry with organising based on features is that I basically get this web of them spread around my app cause again a lot of them do depend on each other
like upsertAddress will depend on create and update
and also upsertAddressSchema and upsertAddressInputSchema should be kept basically in sync but feature wise are in pretty different paths etc etc
There is probably some good DDD bounded context thinking that can help here. Figuring out what the bounded contexts are, what the contracts between contexts are, etc.
vague handwaving
Yeahhh I should read up on that
cause granted I really am quite a noob, this is basically my first "real" project so it's very much learning as you go thing. Do thing, make it work, scope expands, realise it's not maintainable anymore, refactor, repeat kinda thing
yeah, honestly that's better than trying to get it perfect right at the beginning since it can take some time to discover what the nature of both the domain and the solution you're building is.
One thing I do for that is that I put shared things "up one level" until all the dependents are below it. Kind of same as when you lift shared state in react components. So if you have these features:
If
f1 and f2 share something, I put it in the b folder. If f3 or f4 also depend on it, I move it up to a. If "everything" depends on it, I move it out of feature completely and instead put it in shared or common or something like that.
Another thing I've started doing is just to re-use a lot less. We have for example several large forms that users can submit, and they often share a lot of the same validation. But generally I always just duplicate it, because sharing it tends to just make things more complicated and harder to maintain. At some point, one of them will change, and it's so much easier to change it when I know it doesn't affect anything else.