-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate validation into own package #38
Comments
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 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:
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 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. |
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.
The text was updated successfully, but these errors were encountered: