support value parameters for length and range; no longer support functions that return value parameters (7ef2630)

BREAKING CHANGES

The getValidatorProps approach was causing some usability troubles:

Constructing validators became unpredictable

The built-in validators were quite powerful, yes, but they were simply too flexible

The overabundance of flexibility made it hard to grok what was happening because there was too much magic

Creating validators became too difficult

It raised the bar too high for validator authors to adopt the same level of magic flexibility

And it was unclear what would happen if some validators did not adhere

To address these issues:

Validators no longer take ordinal params in the flexible way -- instead, there's just a single props object supplied

That props param can be a function that returns the props object

Context is passed to said function, but there's just a single props object/function now instead of a magic chain of them

The validate function reliably puts value on context and the result props -- no validators are responsible for doing that

Even though using a props object parameter is more verbose for basic scenarios, it makes the API more predictable and therefore approachable.

Additionally, the props validator was badly named. The "props" concept is used throughout Strickland and the name collision between concept and validator was hard to keep clear. It is now named objectProps.

BREAKING CHANGES

The built-in validators were quite powerful, yes, but they were simply too flexible

The overabundance of flexibility made it hard to grok what was happening because there was too much magic

Creating validators became too difficult

It raised the bar too high for validator authors to adopt the same level of magic flexibility

And it was unclear what would happen if some validators did not adhere

To address these issues:

Validators no longer take ordinal params in the flexible way -- instead, there's just a single props object supplied

That props param can be a function that returns the props object

Context is passed to said function, but there's just a single props object/function now instead of a magic chain of them

The validate function reliably puts value on context and the result props -- no validators are responsible for doing that

Even though using a props object parameter is more verbose for basic scenarios, it makes the API more predictable and therefore approachable.

Additionally, the props validator was badly named. The "props" concept is used throughout Strickland and the name collision between concept and validator was hard to keep clear. It is now named objectProps.

The validateAsync result prop is now a function instead of a Promise. The function will return a Promise, allowing the Promise to be deferred until validateAsync is called. Validators can now return either a Promise or a function to opt into async validation, or put either a Promise or a function on the result as the validateAsync result prop. Results will always be normalized to have validateAsync be a function that returns a Promise.

BREAKING CHANGES

Validator Context and Validation Context are being removed. A new design will introduce Validator Props and Validation Context, where Validation Context will NOT be spread onto results.

The validateAsync result prop is now a function instead of a Promise. The function will return a Promise, allowing the Promise to be deferred until validateAsync is called. Validators can now return either a Promise or a function to opt into async validation, or put either a Promise or a function on the result as the validateAsync result prop. Results will always be normalized to have validateAsync be a function that returns a Promise.

Features

Bug Fixes

Re-implemented async again after realizing props, each, every, and some were conflating their responsibilities with validate and they were not returning granular promises--turned async into a new convention favoring resolvePromise at the core. (9d41daf)