Home

• Do we need sometimes to specify validators order? Should we break validation chain if some validation fails?

====

• Whether to validate the empty/not exists values and values are not a suitable type?

• Empty/not_exists values and values are not a suitable type are valid
  ➕ validators become simpler
  ➕ most of validators return one type of message
  ➕ you don't need to duplicate type or empty validation in every validator
  ➕ order of validators doesn't important
  ➖ you need to combine validators in application. In fact type validator becomes mandatory in most situations
  ➖ you can miss values of incorrect type as valid

  • Angular 2: if (isPresent(Validators.required(control))) return null;. e.g. number + minLength validator = valid

• Empty/not_exists values are valid. Values converts to correct type or to default value
  ➕ validators become simpler
  ➕ most of validators return one type of message
  ➕ you don't need to duplicate type or empty validation in every validator
  ➕ order of validators doesn't important
  ➖ you need to combine validators in application. In fact type validator becomes mandatory in most situations
  ➖ you can miss values of incorrect type as valid, but it will be not important for reducible types

  • Angular 1: return ctrl.$isEmpty(viewValue) || viewValue.length >= minlength;

• Empty/not_exists values are valid, values of not suitable type are invalid
  ➕ one validator for many common situations
  ➕ you never miss incorrect type values
  ➖ validators become complex
  ➖ validators have duplicated logic and messages
  ➖ validators like length return error 'must be a string or an array', but generally you have specific type and you need specific error (f.e. 'must be a string'). That is why you need special string validator before

  • Validate.js: if (v.isEmpty(value)) { return; } if(!v.isNumber(length)) { return "has an incorrect length"; }

• Empty/not_exists values and values are not a suitable type are invalid
  ➕ one validator for many common situations
  ➕ you never miss empty or incorrect type values
  ➖ validators become complex
  ➖ validators have duplicated logic and messages
  ➖ you need to set extra flag for validate values which can be an empty
  ➖ validators like length return error 'must be a string or an array', but generally you have specific type and you need specific error (f.e. 'must be a string'). That is why you need special string validator before

====

• How to validate incorrect type/empty values in other validators (use this.validatorName or [validator1, validator2] format)

====

• What should be the strict (==/===) default setting for min, max, equal etc. validators?

====

• Which validators should be in library and What should be validator names and params?

Common

• custom
• validate
• required | presence | empty

Types

• object
• array
• number
• integer
• string
• date
• boolean
• null

Equality (valid if value is empty)

• equal (strict)
• confirm (strict)

Numbers (valid if value is not number or empty)

• max (inclusive=true)
• min (inclusive=true)
• range (from, to, inclusive=true, fromInclusive=true, toInclusive=true)
• odd
• even
• divisible

Length (valid if value is not string or not array or empty, inclusive flag isn't necessary because length is integer)

• maxLength
• minLength
• rangeLength
• equalLength

RegExp (valid if value is not string or empty)

• pattern | format

White and black list (valid if value is empty)

• inclusion
• exclusion

Date and time (valid if value is not valid date)

• maxDateTime
• minDateTime
• rangeDateTime
• equalDateTime
• maxDate
• minDate
• rangeDate
• equalDate

Web (valid if value is not string or empty)

• email
• url (allowLocal)

====

• What should be compared value name?

• rule ?

• comparedValue

• arg

• argument

• target

эталон

• standard
• model
• etalon
• gage
• sample
• master form
• base

критерий

• criterion
• canon
• yardstick
• norm
• test
• benchmark

ограничение

• limitation
• restriction
• constraint
• restraint
• curb

шаблон

• templet
• mask