With the validation problem space well understood, Strickland sets out to achieve many challenging design goals.
Remain decoupled from the UI
Take no dependencies on other libraries
Supply only primitive built-in validators
Enable consumers to easily create their own validators
Provide simple composition features for complex validation logic
Maintain a low concept count
Permit both synchronous and asynchronous validators
Support any possible interaction model
Allow boundless extensibility for any application scenario
Strickland does not have any dependencies on other libraries.
Strickland does not aim to be a bloated collection of validators. Only the most primitive validators are built-in so that Strickland remains a lightweight framework.
Strickland makes it easy to create your own validators. A single-line arrow function can be used to start, but the programming model scales with your application. As your validators become more complex, Strickland gives you the flexibility you need.
Strickland provides features to compose your validators together. As your collection of validators grows, you will be able to reuse them throughout your applications without any friction.
Strickland is powerful yet its concept count remains very low. Validators define rules; validation executes validators against values; validation results are returned.
Strickland lets you quite simply introduce asynchronous validation into your application, without having to drastically change your programming model or alter how synchronous validation is performed.
Strickland is unaware of how your users are interacting with your system. Because Strickland is completely stateless, you can invoke validation whenever and however you'd like. You can invoke UI form validation on keypress, after an idle timeout, on field blur, on form submit, or any combination of these events. You can build server-side validation using the same validator code and execution patterns.
A validator can easily execute other validators, which is demonstrated with arrays of validators and object validation.
Dynamic validators can be created using validator factories.
Validators can receive props using objects or functions that return objects. Those functions can receive validation-time context so that application state can be used within validation rules.
Validators can return booleans, objects, Promises that resolve to booleans or objects, or functions that return Promises that resolve to booleans or objects. Strickland normalizes all of these into consistent and predictable validation results.
Your application is responsible for providing all of the validation result properties, even validation messages. This approach ensures that your application can extend Strickland to meet any functional requirements. Localized messages, warning-level validation results, async progress indicators, UI rendering hints, or any other functionality specific to your platform or application can be applied as a first-class feature.