Hello! I have released a first version of the val...

# feed

[dimsuz]

Hello!

I have released a first version of the validation library based on the idea I haven't seen implemented in similar kotlin libraries: separation of pre- and post-validation models. Also the goal is to make validators (rules) highly composable.

More details and examples here:
https://github.com/dimsuz/vanilla

[Roukanken]

Looks interesting from readme

one question tho

val validator = PersonDraftValidatorBuilder<String>()
  .hasNotNullAgeAtLeast(age = 18, "expected not null age of at least 18 years old")
  .build()

is this correct in the readme? Shouldn't it be

.age(hasNotNullAgeAtLeast(...))

?

[dimsuz]

right! thanks, I'll fix this!

[Big Chungus]

I'm guessing it's jvm only. You might want to have a section in the readme listing supported platforms to avoid confusion

[dimsuz]

Yes, I should specify this. Do you have any links at hand where I can see this section (to steal formatting ideas 😉)

[dimsuz]

I guess I'll make it multiplatform at some point, absolutely nothing jvm specific there...

[Big Chungus]

The main blocker is mpp processor. I'd wait until ksp is multiplatform and build on top of that

[Big Chungus]

As for formatting, nothing special there. Just a markdown list of supported platforms per module. Or you can use shield.io badges

[dimsuz]

Oh, right! Completely forgot about kapt usage. Waiting for ksp too...

Thanks for badges idea!

[stojan]

Nice, Parse, don't validate

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/

[dimsuz]

Exactly! Love this article. I was inspired by applicative validation in FP languages (haskell, purescript), which makes validation such an elegantly solved problem. Sadly it's not that trivial to do without code generation, kotlin doesn't have currying etc. Also turns out kotlinc sometimes just can't infer generics where more powerful type inference systems can (I even filed a bug, but wontfix), so I had to invent a few additional APIs to reduce amount of required manual type specifications when composing validators.

[Big Chungus]

Try migrating to ksp now, make your life easier when it's mpp 😀

[dimsuz]

I should try it! It seems like it's stable enough, I've seen quite a few kapt based (android) libraries create experimental releases based on KSP

[Matteo Mirk]

Hi, it seems a very cool library but I don’t understand completely some design choices:
• why does it enforce this pre/post separation, in having a temporary source type, which can be invalid and the valid destination type, possibly different? Is it made for an interaction between DTO and Domain Object?
• Vanilla seems to be both a validator and an object mapper: isn’t this too much responsibility for the lib?

[Andrzej]

Hi, I really like the approach where successful validation is reflected in a type system!

I didn't have time to investigate the usage, but based on examples I suspect it only supports transformation between two specific types right?

I'm asking because I have a use case where I get data in some very generic format. Depending on its properties, I want to have different validation and result type.

Is something like this possible or do you consider adding support for such use case?

I guess I'd be fine just executing multiple validators and further processing the successful results, although it might be a challenge to recognize if certain validator failed, because it's not the expected target type or because some other validation rules were not fulfilled.

[dimsuz]

@Matteo Mirk it's the explicit design choice to separate these two models. One can be your FormData, other can be what you send to server. Without separation you'd have to insert !! everywhere for example when nullable form field is non-null in resulting model.

As for you second point, it's actually more like a parser with configurable rules, it parses one structure into another, with possible errors if parsing fails. For motivation you can read the excellent "Parse don't validate" article linked in this thread above.

[dimsuz]

@Andrzej generally this library is aimed to allow highly composable chains of validator functions, so in theory you can build a "top" validator which distinguishes between your generic format, then link specific validators down the chain, depending on what validator this "top" one will output.

Errors are accumulated in the output list, including errors from all "nested" validator functions, so no error should be lost.

I guess it would be better to try all this on a specific example to see some cases which can pop up, and how it is best to solve them.

[Matteo Mirk]

Thanks for clarifying, I’ll read the article.

[Matteo Mirk]

Very great article, loved it! Haskell is very elegant. I already had a general intuition of this concept, and tried to apply it in my work… a good read indeed, thanks.