schm
schm copied to clipboard
Separate validation into own package
Hi, I am rising this issue in order to considerate removing the validation feature from the core, for the following reasons.
Not every project requires validation and most importantly not every project can or should support Promises. Keeping the current validation implementation as an optional package would additionally decrease the core size and help on the separation of concerns.
Thank you for considering, and for maintaining this project.
At least we could consider removing the Promise dependency. What is the reason behind it usage?
@miljan-aleksic Thank you for your feedback.
That's because it's possible to have async validations (by just returning promises from validate
prop).
I don't like the idea of removing the validation feature from the core package altogether. Validation is an inherent feature of any schema library.
I think about two possibilites:
- Make
validate
synchronous and add anasyncValidate
method; - Use a polyfill in order to make promises work on old browsers/platforms.
Just for curiosity, what environment is your project targeting?
I am targeting a browser environment, but is not about compatibility with older ones, is more about easy of use.
For example in my project I am validating an array of Table Rows and would like to report about the errors at once, specifying the row id or index. When using promises I cannot simply iterate and collect the errors, I have to use workarounds adding complexity and maintainance issues.
Your first proposal, making validate synchronous, seems appropriate and would solve the above usage case.
I would like to second the idea of a validate
and asyncValidate
. My use-case is that I have an array of objects that also have schemas defined. Depending on the type
value, I determine which schema definition the object belongs to. I would then like to pass off the validation of that item to it's corresponding validator.
The problem is that the validators are all synchronous functions, but the validate() method is asynchronous on the schema object.
Maybe I'm just missing something, but it seems beyond opinionated to force us to validate asynchronously. I don't quite get why you wouldn't let consumer code choose which way to do it. That's simply not an option for the codebase I'm trying to choose a schema package for, so, unfortunately, though I like a lot of things about schm, this inflexibility is a deal-breaker.