Validation schema
Specification
Validation schema is a plain JavaScript Object with the keys representing field selectors, and the values—validation resolvers associated with them.
Selector is a key path that selects the field(s);
Resolver is a pure function that returns the next validity state of the field(s);
Think of declaring validation rules as of applying CSS properties. To apply a CSS rule you first select the elements (fields), and then describe their properties (rules). Validation schema is designed with the same principle.
Definition
Declaration
Here is an example of a simple validation schema:
There are a few resolvers applied in the schema above:
For all fields of
[type="password"]
:Anonymous resolver that validates a field's value length.
For all fields of
[name="vatNumber"]
:Named
format
resolver that validates the format of the field's value,Named
hashsum
resolver that validates the hash-sum of the field's value.
Priority & Exclusion
To get the most of the validation schema it's important to understand the priority and exclusion of the rules described in it. This is what powers the layered nature of a validation schema.
Priority
Validation resolvers are executed with the following priority relevant to the selected fields (listed from highest to lowest):
Synchronous validation
schema.type[fieldProps.type]
schema.name[fieldProps.name]
Asynchronous validation
Synchronous validation always precedes any asynchronous one, because it's meant to ensure a valid value format, while asynchronous validation validates the validity of the data. Combined with exclusion, you can rest assured that asynchronous validation operates on the valid format only.
Exclusion
Exclusion is a characteristic of a validation schema that prevents some validation rules from being executed whenever a preceding rule rejects.
Take the next implementation as an example:
Example above declares three validation points (application levels):
Asserting the correct format of the
[type="email"]
fields;Asserting the entered
[name="userEmail"]
is not in the blacklist;Validating entered user e-mail against a backend;
Taking into account the invalid initial value of the userEmail
field, the validation chain will look like:
Status
Application level
schema.type.email
skipped
schema.name.userEmail
skipped
asyncRule
If the value of the field becomes joe@doe.com
(valid format, but included in the blacklist), the application layers will look like:
Status
Application level
✅(valid format)
schema.type.email
schema.name.userEmail
skipped
asyncRule
Each of these application levels is exclusive, meaning that whenever it rejects (returns false
as a field's next validity state), the succeeding resolvers will not be executed.
Applying schema
Application-wide
We highly recommend to apply a validation schema application-wide.
Form-wide
Extending a schema
A validation schema may be extended, or overridden, using the root-level extend
property.
Once set to true
, the current schema is deep merged with any higher-scope schema (i.e. the one from FormProvider
). When set to false
, the current schema will override any higher scope schema, and be used as-is.
Last updated