Default configuration

[bejibx]

Hi! I notice that right now the only way to change validation config is to explicitly pass configuration object during Validator creation. This could be cumbersome if you want to change your configuration globally. One example might be to collect violations in debug version of your app but fail on first one in release version for better performance. Right now to do something like this you have to either pass config into every validator or to declare some wrapper method to create validators inside your code. I don't like both solutions so I'm curious if you see as an reasonable solution to instead add to the library some way to specify default globall configuration? If you ok with the idea, I'm ready to implement it.

Oh, by the way another bonus of keeping default configuration instance somewhere would be reduced number of object creation. If I'm not mistaken right now every Validator creation also creates 2 instances of Configuration (one for default value in Validator.invoke(...), another for default value in Configuration.invoke(...)). Instead we can just point to our default same instance. This might sound silly for some people, but I worked on some mobile projects where I had to do some evil black magic to decrease number of creating objects to reduce garbage collector load.

[nesk]

Hi,

I already tought a lot about this and my main concern about this is I don't want Akkurate to manage any kind of singletons in its own codebase.

My first response was that users should wrap Akkurate by themselves and provide a default configuration. For example:

fun <T> AcmeValidator(block: Validatable<T>.() -> Unit) = Validator(Configuration {
    defaultViolationMessage = "The field contains an invalid value"
}, block)

fun main() {
    AcmeValidator<String> { 
        isNotEmpty()
    }
}

However, after reading your message and diving a bit more into this, I realize how complex this is. The AcmeValidator doesn't support contextual values nor any suspendable code.

To support those, the users would have to create a wrapper for each of the Validator functions. This is complex, error-prone and discouraging.

So I agree, yes, global configuration should be something provided by Akkurate!

However, I still want to avoid Akkurate to manage any kind of singleton to store the global configuration. So here's my take:

// Declare as many preconfigured validators you need, instead of a single global configuration.

val BooksValidator = Validator.preconfigured(Configuration {
    rootPath("books")
})

val OrdersValidator = Validator.preconfigured(Configuration {
    rootPath("orders")
})

// For each preconfigured validator, you can override its configuration, provide
// contextual values, and even use suspendable code.

fun main() {
    // Simple validator
    BooksValidator<String> {
        isNotEmpty()
    }

    // Configuration overridden
    BooksValidator<String>(Configuration { defaultViolationMessage = "This is wrong" }) {
        isNotEmpty()
    }

    // With contextual values
    BooksValidator<SomeDao, String> { dao ->
        isNotEmpty()
        constrain { /* use the dao */ }
    }
    
    // Suspendable validator
    BooksValidator.suspendable<String> { 
        isNotEmpty()
        // call some suspendable code
    }
}

Akkurate doesn't store any kind of configuration, its up to the user. As a bonus, it is also possible to create multiple configurations for various use cases.

Is this something that would fit your situation?

[bejibx]

My concern is right now there is no way to enforce usage of these predefined declarations, everybody can still declare validators using default factory methods without our default configuration. Such enforcement might be implemented with some custom lint rules, which I know how to do only for android linter, never wrote rules for other. Another possibility is to move entrypoints into a separate module, this way it can be applied using api configuration to "proxy" project module where actual entrypoint would be defined. Actually, I like this option quite a lot after thinking about it for some time. What do you think? Maybe you have other ways in mind how can this be done?

Also, can you please elaborate a little bit more on you position regarding singletons?

[bejibx]

I was thinking about separate gradle subproject for entrypoints only, but I just looked more carefully into library code and nah, it would be too complicated. I can try to add modules for library specific lint checks, might be interresting to finally figure out how some kotlin linters work.

Can we at least add default immutable configuration instance and use it inside library instead of creating new objects every time we need an instance? I really like this library syntax more than other similar alternatives, but right now it's really hard to convince my colleagues to use it for this particular reason. We have some pretty busy mappers in our project for which we're really trying to minimize object creation. Sometimes using absolutely unforgivable hacks.

[nesk]

Can we at least add default immutable configuration instance and use it inside library instead of creating new objects every time we need an instance?

I'm not sure what you want here? The Configuration class is already immutable:

val config: Configuration = Configuration { // this: Configuration.Builder
    defaultViolationMessage = "hello"
}

config.defaultViolationMessage = "hi" // ❌ Cannot assign to 'defaultViolationMessage': the setter is private in 'Configuration

Here, the config variable is immutable and can be passed to your validators without allocating any new Configuration instance.

Or did I miss something?

[bejibx]

Oh, nevermind, turns out I was confused by Validator and Validatable classes, thought Configuration.invoke() was called on every validatableOf call, which in fact is not true, so it's not that big of a deal. What I was suggesting is to create some internal instance for default configuration and use it as default value for Validator factory methods:

internal val defaultConfiguration = Configuration()

public sealed interface Validator {
    public companion object {
        public operator fun <ContextType, ValueType> invoke(
            configuration: Configuration = defaultConfiguration,
            block: Validatable<ValueType>.(context: ContextType) -> Unit,
        ): Runner.WithContext<ContextType, ValueType> = ValidatorRunner(configuration, block)
    
        // ...
    }   
}

[nesk]

You're right, this is a small optimization I can add! I've created an issue for this.

Do you want me to create a new issue to implement the preconfigured validators, as described in this reply?

[bejibx]

Great! Thank you!

[bejibx]

Let me try to sum up what we got.

1. Global configuration is a good idea overall
2. It should be implemented by adding some sort of Validator factories containing predefined by user configurations
3. Proposed api is to add Validator.Companion.preconfigured(Configuration) method which will return some new type implementing same methods as Validator.Companion but using his own configuration instance as a default value
4. In cases when someone needs to restrict creation of validators to use specific preconfigured entrypoints - custom lint checks on user side is a good solution
5. It's possible to optimize validators creation a little bit by reusing same Configuration instance for default values in methods - Create a singleton for the default configuration #52

Please correct me if I misundertood you somewhere.
I don't really care about if it's gonna be an issue about this change or not, do as you see more comfortable. I can try to implement this myself, just tell me a little bit more about this implementation you have on your mind. In this case issue containing some implementation details might be helpfull.

[nesk]

I think you've summed up the situation really well :)

just tell me a little bit more about this implementation you have on your mind

The factory methods should be extracted to an interface, let's name it ValidatorFactory. Then the Validator.Companion object extends this interface, but the implementation can be probably stay the same than nowadays.

We must add a preconfigured(Configuration): ValidatorFactory method to the Validator.Companion object. The returned value is an instance of some class (PreconfiguredValidatorFactory?) that implements ValidatorFactory and stores the Configuration provided to the preconfigured method.

A next step could be to allow partial configuration overriding of the preconfigured validators, but let's ignore this for the moment, we'll think about this later.

[nesk]

I've created an issue to track this: #54