<@U02SEA99VJB> AFAIK `otherwise { }` only supports...

# akkurate

[dave08]

@Johann Pardanaud AFAIK otherwise { } only supports strings right? It's not so great when validating forms in Jetpack Compose where an error is an R.string.XXX (an Int...)... any chance of expanding that to support other types?

[Johann Pardanaud]

Yes! I will improve this in the future, we already have two issues to track this:

• https://github.com/nesk/akkurate/issues/34
• https://github.com/users/nesk/projects/1/views/1?pane=issue&amp;itemId=38823597

[Johann Pardanaud]

Clearly, this is something missing

[Johann Pardanaud]

However, I would appreciate an exemple of your code to have a better comprehension of your own issues and your expectations. Could you provide me a sample?

[dave08]

I'm not so sure Akkurate needs to be an i18n library... lets take your overview example:

val validateBook = Validator<Book> {
    title.isNotEmpty() otherwise { R.string.missingTitle }

    releaseDate.isInPast() otherwise { R.string.releaseDateMustBeInPast to listOf(releaseDate.value) } // In some cases a stringResource is a template with interpolation of values so here it would be nice to pass in a Pair...

    authors.hasSizeBetween(1..10) otherwise { R.string.wrongAuthorCount }

    authors.each { 
        (firstName and lastName) {
            isNotEmpty() otherwise { R.string.missingName }
        }
    }
}

[dave08]

Then let the user choose whatever framework they're already using...

[Johann Pardanaud]

Akkurate won't be an i18n library, but it has to connect to existing ones, which means providing more context.

[Johann Pardanaud]

Including support for other types than String 🙂

[dave08]

Basically a resource id and some parameters for interpolation is what's needed (sometimes the id is not a String and the parameters could be any type)... that's why the simplest way would just be to allow the user to decide what they want to get back in their constraint violations... metadata forces the user to have a MapString, String (maybe I'm wrong, but that's the example from that issue...) and translateTo forces to map strings to R.string.XXX keys... or maybe I'm misunderstanding?

[Johann Pardanaud]

This is currently under consideration, the issue has been created by an akkurate user but it probably wont be implemented as-is. I agree with you, the real feature is being able to return whatever you want

[Javier]

I think this is the same problem Result has and Either fixed. The left part not being a generic and force to use Exception.

Validator<Int, Book> { }

Validator<() -> String, Book> { }

If it uses a generic you wouldn't need any integration with any library, but you can still provide bindings for them anyway.

Not good names but to show some samples:

ValidatorOrResource<Book> { }

ValidatorOrComposeResource<Book> { }

[Johann Pardanaud]

That's good examples actually, thank you! I will probably implement something like that 🙂

[dave08]

I'm just wondering if the user has access to the current value being validated, so that when returning a resource one can return values to be interpolated in them like The book %s is invalid needs the book name there...

[dave08]

That's why I had a Pair<Int, List<Any>> returned in one validation up there...

[dave08]

Not all of the messages would need interpolation though

[Johann Pardanaud]

The validated value will be available, this is something that has already been requested in this thread: https://kotlinlang.slack.com/archives/C061JJM6YUQ/p1729757849008129