Monad are containers with ‘special powers’, when it comes to applying function over its content.
Validation special power is propagating Failure over validation process.
If you are not familiar with scalaz.Validation I urge you to read this example, which shows how to use Validation: A Tale of 3 Nightclubs
Basically validation looks like this:
Scalaz.Validation uses idiomatic scala way to compose monads by For Comprehension.
Concrete validation method, returning scalaz.Validation instances looks like this:
Scalaz provide helper methods for wrapping values into Failure or Success.
To sum it up. Validation is a an elegant way to handle application validation logic.
However it’s not enough.
Our business rules require application logic’s to perform validation with warnings, which should not propagate as failures, but rather propagate independently of Success/Failure types.
We liked monad approach to data validation so we wanted to keep it that way.
Let me introduce Validation with warnings
What it does is basically wrapping scalaz.Validation into another type responsible for carrying warnings over validation process
Thank to scala type inference our validation code look’s just the same, but now for expression operates on ValidationWithWarnings type rather than Validation.
OK, but what about validation code? We created similar helper methods for wrapping validation into ValidationWithWarnings and wrapping values directly into warnings.
One could inline warning in for loop:
Or use it in validation method:
And of course chain it in for-loop:
Applicative
Summing
Similarly to scalaz.Validation, we also support summing values, if value type has Semigroup typeclass:
Repository
Q&A
– Same reason why we prefer Validation over Either with left/right projection. It’s more direct and descriptive.
Why validation nel underhood?
– It suited our business needs best.
Validation is not a Monad!
– True.
