Validation of strings with validate.it.js

If we recall all the technical specifications with descriptions of field validation, they always looked like this:

• must not be shorter than 6 characters
• must not exceed 12 characters
• must include only latin characters, numbers and underscore

Requirements often come with a set of simple unambiguous phrases. And we, programmers, translate these requirements into code.

You can turn them into one ultimatum regular expression, like

const validateLogin = login => /^[a-zA-z_\d]{6,12}$/.test(login); 

But it is better to write simpler functions that are easier to read and associate with direct TK:

 const charMatch = new RegExp('^[a-zA-Z_0-9]*$'); const validateLogin = login => { if (login.length < 6) return false; if (login.length > 12) return false; if (!charMatch.test(login)) return false; return true; }; 

And what if even more to simplify this code to something like:

 const validateLogin = login => validate(login) .notLessThan(6) .notLongerThan(12) .hasOnly(['a-z','A-Z','0-9','_']); 

The basic idea is that validation requirements can often be decomposed into a list of independent typical statements. And these asserts can be collected into a collection and reused.

This is exactly what the validate.it.js library does. The core of which does not exceed a hundred lines and does not so much:

• allows you to call assertions chainly
• collects and processes the results

The above means that by running a code like this:

 validate('Pa$$w0rd') .hasLettersLatin() .hasNumbers() .has("!", "@", "#", "$", "%", "^", "&", "*", "(", ")", "_", "+"); 

You will get this result.

 { ok: true, base: 'Pa$$w0rd', asserts: ['hasLettersLatin', 'hasNumbers', 'has'], errors: [] } 

I think it's obvious, but I'll sign for a bit

• ok bool - validation status
  
  • true - validation was successful
  • false - validation failed
• base string - validated string
• asserts array - a list of names of called assertions in the order of their call
• errors array - an array of reports in the format of the Validation Report of all failed assertions

Here is an example of failed validation.

 validate('bob') .hasLettersLatin() .hasNumbers(); // --> { ok: false, base: 'bob', asserts: ['hasLettersLatin', 'hasNumbers'], errors: [ { path: [], rule: 'hasNumbers', details: { string: 'bob', subStrings: ["1","2","3","4","5","6","7","8","9","0"], found: false, message: '"bob" has no numbers' } } ] } 

This simple idea allows you to write a validation code as close as possible to the requirements. At the same time, the assertions themselves are very simple and are pure functions . They are easy to maintain, test, and add new ones.

By the way, yes, if you are missing some assert, you can easily add it via @static .extend on-the-fly or use assert .eval .

But do not be greedy for your community assertions. Become a contributor!

To contributors

And now a surprise. Themselves assert'ov the library is still almost there. Just a couple of basic ones like .has , .match , .eval and some more for examples. There are not even those that I used in the listings of this post. The thing is, I wanted to draw attention to the idea, not to the implementation.

Moreover, I believe that my vision of the necessary assertions can be very different from the vision of the community. And, making this tool "by itself" I can make it inconvenient for other JS developers. And I had an idea - to involve the JS community in the creation of this tool. Whatever do nothing yourself he covered the needs of the community, not my own.

I invite JS developers to become validate.it.js contributors.
Anyone who wants to contribute to open source, but does not know which project to start.
Anyone who wants to make for themselves and for the whole community a convenient validation tool.

Together we can fill the collection with assertions that we all really need.

In this case, the contributor may be a developer of any level. After all, someone wants to do validation on the length of the line, and someone, for example, is more interesting to implement a check for compliance with the date for all versions of ISO 8601.

There are very soft requirements for pull-requests:

• availability of tests
• the presence of the description - to insert it into the section with the list of assertions.

Validation Report

Speaking of the aforementioned .errors which fill an array of .errors in the case of failed asserts. I was looking for some standard to represent validation errors. And from my own experience I knew that the banal true / false and even null / 'error message' not enough. And apparently, there is no such standard today.

But there is a great idea of ​​a habrauser rumkin

"Universal Validation Report Interface" - @rumkin / Validation Report . git

This is a simple DTO that allows you to transfer as much detailed information as possible about the failure of validation. Consists of:

• path array - the location of the scan object. In the context of string validation, this is always an empty [] array.
• rule string is the name of the assert or the rule that was validated.
• details object - details or description in a “machine-readable form” of the reason for a validation failure. This parameter has no clearly-standardized structure, except for one field:
  
  • details.message string - a description in "human-readable form." This is not a standard field for VR, but is required for this project.

Example:

 { path: [], rule: 'notLongerThen', details: { string: 'markopolo', length: 9, max: 6, message: '"markopolo" longer then 6 characters' } } 

rumkin , by the way, wrote a small tool for generating Validation Reports. but for the sake of 0Dependecy, I do not specifically use this implementation. The benefit of VR generation is quite a simple task.

It will be great if VR becomes a standard one day, at least local.

PS

Feel free to ask questions - I will only be happy to expand the contributer's guide or readme project.