preface

When adjusting the interface with the back end, there will always be data verification problems, sometimes the problem is also a sentence, I think the back end will verify, or I think the front end has been verified. More directly, you can see ABC, which is something that you check on the front end, but I don’t check on the back end. In order to improve the robustness of the code, data validation is really essential for us.

Just recently have some spare time, on their own a do object value verification, feel can solve the common development of most of the verification problems. Of course, for the sake of code rigor, post the results of the unit tests.

100 percent coverage, 43 test cases, forget unit tests, attitude is here

verify-data-js

Github address: github.com/lyingdog/va…

The installation

npm install verify-data-js
Copy the code

use

const Validator = require('verify-data-js');

const data = {
  arr: [1.2.3].list: [1.2.3.4]};const validate = new Validator(data);

const errs = validate
  .all(["MAX_LENGTH:4"."MIN_LENGTH:1"].'Length out of order')
  .allWithout(["MIN_LENGTH:3"]."The length does not conform to the rules.")
  .every(v= > v.every(n= > n > 0), 'Values do not match')
  .some(['arr'.'list'].v= > v.length > 3.'Array length does not match')
  .expect('list'."MAX_LENGTH:1".'List cannot be longer than 1')
  .expect('list'."R_EQUAL:5"."The fairy of Balala.")
  .relative('arr'.'list'.(v1, v2) = > v1.length > v2, 'The length of arr cannot be less than the length of list')
  .compare((data) = > {
    console.log('compare get data', data);
    return true;
  }, 'Test compare to get data')
  .end();

console.log('errs', errs);
/ / /
/ / {
// type: 'every or some',
// key: 'arr',
// value: [ 1, 2, 3 ],
// MSG: 'Array length does not match'
/ /},
/ / * * * *
// ]
Copy the code

Method of use

Rules and how to use rules {"REQUIRED": "Must enter"."IS_DIGITS": "Integer"."MAX": "Maximum number".// MAX:3
  "MIN": "Minimum number".// MIN:5
  "MAX_LENGTH": "Maximum length".// MAX_LENGTH:5
  "MIN_LENGTH": "Minimum length".// MIN_LENGTH:5
  "REGEXP": "Regular".// REGEXP:/bbb/
  "PHONE": "Phone number"."TEL": "Mobile phone number"."EMAIL": "Email"."TYPE": "Type" // TYPE:array} rules that require [:value] are commentedapiRules can be a string or an array. An array means that each rule must be specified"MAX_LENTH:3"| | ["MAX_LENGTH:5"."MIN_LENGTH:1"]

// All values satisfy the rules passed in, MSG is the error MSG to be returned
all(rules, msg)

// All values except keys satisfy the rules passed in, where MSG is the error MSG to return and keys is the list of keys to exclude
allWithout(rules, msg, keys = [])

// The specified value satisfies the rules passed in
expect(key, rules, msg)

// Each value satisfies the value condition, value is a value, or callback, data can be passed or not, the default is this.data
every(value, msg, data)

// Some values (values in the keys list) satisfy the value condition, value is a value, or callback
some(keys, value, msg)

Callback (v1, v2); callback(v1, v2);
relative(k1, k2, callback, msg)


//@description custom comparison
//@param callback {function} the comparison rule will pass this.data as the first argument
//@param MSG {string} fails
compare(callback, msg)

// Must be used at the end to indicate that the verification is complete, and return an array with a problematic verification length of 0, indicating that the verification has passed
end()

// Add a custom rule in the format R_*
static addRule(rule, callback) {
  rules.push(rule);
  rulesMap[rule] = callback;
}

Validator.addRule('R_EQUAL'.function (data, value) {
  return data === value;
})
Copy the code

conclusion

Writing a readme is really hard. Or brave scalp to write down, preliminary feeling, should be no big problem. It’s going to be used in future projects anyway, so the code isn’t that hard. It is equal to training hands, the project always starts small, gradually grows big. Write one more line of code and you may be one step closer to your dream