I’ve started using the dry ecosystem in various parts of our fairly standard Rails application (in production). We really like the DSL that dry-validation/schema provides and think the idea behind separating schema/structure validation from domain validation is great.
However, we want to take the separation further and actually report the violations from those separated validations differently. For example, we have a JS front-end for a signup form which posts via fetch to our backend. We want any structure violations (e.g. missing keys or perhaps the values in the dropdown aren’t what we expect) to raise, so our developers can fix a mistake (rather than the user being told they are missing a key!). We then want the domain validation (“this value must filled”) to be reported back to actual users.
We currently do this with dry-schema at the controller level for validating the structure of the API request and failures here will raise. We then define a dry-validation separately for domain rules. The issue we have with this is that there is a lot of duplication and “redundant” definitions.
For example, through the first structure step we have already required keys to be present and certain types to be defined. It’s a little redundant to then have to redefine keys and types, when they actually aren’t the target of the second validation and won’t be used at all in the errors we show the user.
The solution perhaps is to allow
key(:something) (so you aren’t redefining the required-ness) and allow leaving off a type (which currently works but looks like it’s getting deprecated).
I imagine the real problem here is that this use case isn’t really what you had in mind for these gems and they are more for “pure” API systems where all the errors (both structure and domain) are reported back to the “user”.
Do you have any thoughts on the separation that I am trying to achieve here?