Adding preconstructed condition checks.

[sudojunior]

It's understandable if the declaration of types is sometimes quite tricky, so making use of predefined checks from the module itself would be quite handy. But the choice is to either include it with the root export or create a new file which the dependant can import themselves...

This issue is intended for a first time contributor.

• If you want to contribute by adding any of these methods, please do not feel pressured to adding all of them at once. I would appreciate it if you gave others the opportunity. ❤️
• And if you do add one or more, you may reference it but please do not use the fix or closes keywords. I will handle that on my own accord.

Copied from the README.md located on dev branch at the time of writing.

• validate.checks[key: string](value?: any) => boolean
• validate.checks.exists(value?: any) => boolean
• validate.checks.optional(value?: any) => boolean - Possiblity to move options.optional to this predicate...
• validate.checks.truthy(value?: any) => boolean
• validate.checks.int(value: int?) => boolean

Type bound

This would make use of predicate construction by passing the context of the previous scope through to the child.

• validate.checks.min<T>(n: T) => (value: T?) => boolean
• validate.checks.max<T>(n: T) => (value: T?) => boolean
• validate.checks.between<T>(low: T, high: T) => (value: T?) => boolean

  The generic of T would infer that the accepted type has already been checked or is yet to be checked, but will default to that of primative number.

  • Could also be applied to string or Array when making use of the .length property. Either would work.

[sudojunior]

• validate.checks.literal(...values: any[]) => (value: T?) +> boolean

  Making use of literal equality checking, rather than by class or typeof.

[sudojunior]

• validate.checks.finite(value: number?) => boolean
• validate.checks.between(min: number, max: number) => (value: any?) => boolean

  Expect one of string, number, etc. but possibility to accept all arguments.

• validate.checks.inRange(min: number, max: number) => (value: any?) => boolean

  Same as between but makes use of {equality} or equal to instead.

String specific

• validate.checks.includes(literal: string | any, from?: number) => (arg: any?) => boolean
• validate.checks.indexOf
• validate.checks.lastIndexOf

  Focused on string searching, but can be applied to an array structure if the ~.rest option is not specified.

• validate.checks.startsWith(literal: string) => (arg: any?) => boolean
• validate.checks.endsWith(literal: string) => (arg: any?) => boolean

  Assume any, but expect string.

[sudojunior]

Logical expressions

Most likely not worth the time, the user depending on this library could construct their own logical predicates.

• validate.checks.and
• validate.checks.or
• gt / lt / gte / lte / eq / ne / id / nid

[sudojunior]

• validate.checks.native(type: NativeType) => (arg: any?) => boolean
  The native type would not be to check if the argument is of a literal native identifier (i.e. 'string', 'number', 'object').
  Might be counterintuitive, but on the other hand the library does this in it's core code.

[sudojunior]

The use of custom and composit types in the native conversion method of ~.toString() provides the function itself as a result.

This is not helpful when forming complex options, if turned out to be wrong would be drastically different to what the function explains at a baseline.

(min, max) => (value) => min < value && value < max
// ~.predicate.inRange(min, max) -> value -> boolean # theoretical implementation
// (min, max) -> (value) -> min < value < max

There may be a possibility to provide a predicate class builder instead of the structure intended, but in doing so would make the library itself much harder to understand and implement.