Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃洜 nope-validator v2.0.0 #861

Open
ftonato opened this issue Jun 2, 2022 · 1 comment
Open

馃洜 nope-validator v2.0.0 #861

ftonato opened this issue Jun 2, 2022 · 1 comment
Labels
RFC Ideas & Discussions

Comments

@ftonato
Copy link
Owner

ftonato commented Jun 2, 2022

This is a proposal for the new version of the library: v2.0.0 which implies a complete change (refactoring) of how the data is returned by the library.

The current behaviour is quite simple:

const Nope = require("nope-validator")

const schema = Nope.string().email().required()

schema.validate('me@gmail.com') // 馃煝 returns undefined since there are no errors

schema.validate('invalid-email') // 馃敶 returns a string message with the error: "Input is not a valid email"

There is absolutely nothing wrong with this pattern, however as we are thinking of implementing transformers (handlers for input data), we assumed that it would make more sense to return something different that could benefit users.

So the API return was defined to meet all possible needs, returning not only the error but also the input data and the data that was transformed, as follows:

Key Description
data returns always exactly the input data
transformed returns the transformed data (if any transformation has taken place), otherwise it returns the input data
errors returns an empty array (if there are no errors), otherwise it returns an array of errors

Let's see what the return should look like for both cases (success/error):

馃煝 Success scenario (no errors will be returned)

const Nope = require("nope-validator")

const schema = Nope.string().trim().toLowerCase();
const { data, transformed, errors } = schema.validate('  NOPE-validation  ');

/*
  {
    data: '  NOPE-validation  ',
    transformed : 'nope-validation',
    errors: [ ]
  }
*/

馃敶 Failure scenario (a errors list will be returned)

const Nope = require("nope-validator")

const schema = Nope.string().url('url-error-message');
const { data, transformed, errors } = schema.validate('http://');

/*
  {
    data: 'http://',
    transformed : 'http://',
    errors: ['url-error-message']
  }
*/

You may be wondering, but what are the transformers? And the truth is that currently we don't have many defined, only one that was introduced last week (trim #824), however another one has already been requested, it is the case of (default #641), and along with the new version, we plan to release others, like: (toLowerCase, toUpperCase, round.floor**, round.ceil, round.trunc and round.round).

** By the way, round a.k.a. Math['type'].


If you have any ideas/suggestions or if you'd like to contribute to the release of the new version, feel free to reply in this thread and I'll explain how you can. If you want to keep up with the work in progress, keep an eye on the branch where the temp work is being done: https://github.com/ftonato/nope-validator/tree/feat/nope-2.0.0.

Thanks for your attention 馃巿

@ftonato ftonato added the RFC Ideas & Discussions label Jun 2, 2022
@ftonato ftonato pinned this issue Jun 2, 2022
@lesha1201
Copy link

It would be nice to change the behaviour of min. Currently it's just an alias to greaterThan but it's more intuitive that it's actually equal or greater than. For example, I would expect this to be valid:

Nope.string().min(8).validate("password");

But it actually should 9 characters to be valid.

The current behaviour also differs from Yup min.

The same applies to max.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Ideas & Discussions
Projects
None yet
Development

No branches or pull requests

2 participants