4 releases (2 breaking)
0.3.1 | May 24, 2020 |
---|---|
0.3.0 | Sep 7, 2019 |
0.2.0 | Sep 5, 2019 |
0.1.0 | Sep 4, 2019 |
#317 in Value formatting
166 downloads per month
Used in 2 crates
(via unftp-auth-jsonfile)
185KB
3.5K
SLoC
valid
Let the business logic only accept valid values!
-
Validate custom types by composing primitive validation functions.
-
Use one common API for validating all kind of business rules including aspects of the application state.
-
One common error type for all kind of constraint validations. It is designed to help with error messages that are meaningful to the user of an application.
valid
is a validation library for the Rust language. It let us write validation functions for
our custom types through composition of available validators. Any custom written validation function
again can be used to build validations for even more complex types.
The valid
crate defines the types and traits to implement validation functions and use them to
validate our values. Additionally, it defines primitive constraints.
Most primitive constraints validate one property of the validated type. E.g. the Length
constraint
validates the length property of strings, container types or slices. If the constraint property is
not covered by a trait of the std-lib, a related trait is defined, which we call a property trait.
The builtin constraints are implemented for generic types T
that implement the related property
trait.
One goal of valid
is to provide one common API that can be used to validate all kind of business
rules. Constraints are grouped into one of 3 categories:
- field level constraint, e.g. only a range of values is allowed
- the relation of 2 fields, e.g. 2 password fields must match or 2 fields must define a range
- business rules that verify some aspect of the application state, e.g. a username must be unique
Any violation of constraints are returned in one common error type, regardless of the category of the business rule that defines the constraint.
One principle for the core functionality of this crate is to have no dependencies other than
the std-lib. Support for types of 3rd party crates such as bigdecimal
and chrono
are
implemented as optional crate features. So you can pick and choose which types you need in your
application and which dependencies you will have in your project.
Features
- Common validation API for validating constraints on field values, constraints on related fields and constraints on application state
- Definition of primitive constraints, such as
Length
,CharCount
,Bound
andMustMatch
- Generic implementations of the validation function for the provided constraints
- Composition of validation functions to implement validation for complex types
- One common error type for validation errors of all kind of constraints
- Accumulation of multiple constraint violations
- Separation of the validation process itself and presentation of validation errors
- The
ValidationError
is designed to help with composing detailed and helpful error messages targeted to the users of an application. Localization or internationalization of error messages is not scope of this crate. - The core functionality has no dependencies to 3rd party crates
- Error codes are compatible with the naming convention in the fluent project
- The error type
ValidationError
implementsstd::error::Error
and can be used with thefailure
crate - Serialization and deserialization of
ValidationError
throughserde
(optional crate feature "serde1") - Support for widely used types of 3rd party crates through optional crate features
- Support for
BigDecimal
of thebigdecimal
crate (optional crate feature "bigdecimal") - Support for
BigInt
of thenum-bigint
crate (optional crate feature "num-bigint") - Support for
DateTime
andNaiveDate
of thechrono
crate (optional crate feature "chrono")
Usage
For detailed information on how to use valid
including lots of examples see the
API documentation at docs.rs.
To use valid
we add it as a dependency to our Cargo.toml
file:
[dependencies]
valid = "0.3"
valid
provides some of its functionality as optional crate features. Some features enable support
for validating a type that is provided by this crate. Other features enable the implementation of
additional constraints. To use any optional functionality we must enable the relevant crate feature
in our Cargo.toml
file. All crate features can be enabled in any combination.
Here is an overview of all crate features:
crate feature | supported types | enabled constraints |
---|---|---|
bigint |
BigInt |
|
bigdecimal |
BigDecimal |
|
chrono |
DateTime , NaiveDate |
|
regex |
Pattern |
Additionally the "serde1" feature enables serialization and deserialization of ValdiationError
using the serde
crate:
[dependencies]
valid = { version = "0.3", features = ["serde1"] }
Dependencies
~0–1.1MB
~20K SLoC