Renamed to szg251/elm-validator-pipeline. That is where the repository lives now. It has not been published as a package under the new name.
Versions published as gege251/elm-validator-pipeline still install under that name. 5 versions of 5 come from the new location (see their notes).
Rerouted (renamed, verified). The GitHub user or repository was renamed. The tag is still there, at the new name. The Lamdera package server serves a copy recovered from https://github.com/szg251/elm-validator-pipeline.
What we checked: The repo moved to github.com/szg251/elm-validator-pipeline. Rebuilt with git archive from commit 58c613510d10 of https://github.com/szg251/elm-validator-pipeline (zip prefix gege251-elm-validator-pipeline-9c42f9a/, America/Los_Angeles times): the zip is byte-identical to the one package.elm-lang.org recorded, SHA-1 d3a0cef0a7d4ad2c7c85297f591d3c2d3900a042.
The Lamdera compiler uses this copy and prints a one-line notice saying so. elm itself fails to download this version.
Details · package.elm-lang.org's zip: https://github.com/gege251/elm-validator-pipeline/zipball/2.0.0/
Validators work in a pipeline (or applicative functor style), similar to the one used in
json-decode-pipeline. Values are checked and applied to a function one by one.
If everything goes well, the pipeline returns an Ok result, otherwise it will return all the errors.
Ok ValidatedForm
|> validate (String.notEmpty "name is required") form.name
|> validate (String.isEmail "email is invalid") form.email
|> validateMany
[ String.hasLetter "password needs to have letters"
, String.hasNumber "password needs to have numbers"
]
form.password
|> noCheck form.message
|> checkOnly (Bool.isTrue "you need to approve") form.approvedIn the example above, I used Strings as errors, but they can be any type you want.
Errors will be accumulated from top to bottom into a List. If you want to know exactly which field
had errors, take a look at the Validator.Named module.
Validator is function, that checks a value, and returns a Validated. Some validators can change the type of the value of type a to type b.
Apply a value to the pipeline without perfoming any checks.
Validate a value and apply it to the pipeline.
Validate a value without applying it to the pipeline.
Validate a value using a list of validators. Checks are performed from left to right, and will stop on the first failure, returning only the first error.
Note: validateMany is a convenience function onver validate << many
Validate a value using a list of validators. Checks are performed from left to right, and will return all errors.
Note: validateAll is a convenience function onver validate << all
Map a function into the happy path.
Chain together validators. Only the first error will be returned on failure.
Note: validateMany and validateAll provide a cleaner interface for most use cases.
Transfrom error values.
Compose a list of validators for a single value. Checks are performed from left to right, and will stop on the first failure, returning only the first error.
Compose a list of validators for a single value. Checks are performed from left to right, and will return all errors.
Create a custom validator, using a predicate function.
Validatedis simply an alias for a Result type, with errors as a list of your type, which can be a string, or any custom error type. You will not need to work with some exotic type, this is only here for convenience.