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

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(...))

?

right! thanks, I'll fix this!

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

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

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

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

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

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.

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

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

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?

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.

@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.

Thanks for clarifying, I’ll read the article.