Hi everyone, I'm using Koin with Ktor, and previously I was using Koin in various classes by impleme...

# koin

[gps]

Hi everyone, I'm using Koin with Ktor, and previously I was using Koin in various classes by implementing the KoinComponent interface, and then using inject. I don't need to do this if I'm using it in the context of a route, or application, but I think I do need to do this if I'm using it my own classes? After upgrading to Koin 2.2.0 however, I'm getting a warning asking me to add an annotation: KoinApiExtension. This suggests to me that I'm likely doing something stupid here. Why is it a bad idea for me to implement KoinComponent? Thanks!

[arnaud.giuliani]

KoinComponent is to help you extend Koin API where there is not already extension for your classes

[arnaud.giuliani]

it should be a injection configuration stuff for your app

[gps]

hmm, so it sounds like implementing KoinComponent may indeed be the right thing to do?

[gps]

consider an example like this:

[gps]

import com.typesafe.config.Config
import org.koin.core.component.KoinComponent
import org.koin.core.component.inject

class Foo : KoinComponent {
    private val config by inject<Config>()

    fun doSomething() {
        val foo = config.getString("foo")
        println(foo)
    }
}

[gps]

would that be the right way to be able to use inject from Foo?

[gps]

if so, this requires me to annotate Foo with @KoinApiExtension, which in turn requires an OptIn at all use-sites of Foo. is this the “expected” outcome? i ask because i’m not sure I fully understand why this warning is a good idea (i’m not saying it’s not a good idea - just want to understand why)

[arnaud.giuliani]

yes the OptIn is the way to go to assume your usage of KoinComponent

[arnaud.giuliani]

try constructor injection as much as possible

[ianbrandt]

I'm not sure I follow the intent of this new annotation. The QuickStart and Documentation sites both show using KoinComponent as the gateway API for the container, and neither makes any mention of @KoinApiExtension. Why is it desirable to have to opt in to this API? Is there some other API we should be using instead from 2.2.0 on to achieve the same thing as the `HelloApp`/`MyComponent` examples?

One thing I noticed that seems not desirable is since the retention is AnnotationRetention.BINARY it exposes Koin as an API dependency instead of just an internal implementation dependency.

[arnaud.giuliani]

Interesting point. The thing is KoinComponent is a way to bootstrap Koin where we don’t already have any extensions.

[arnaud.giuliani]

behind that I’ve seen many abuse of such interface. Then I “push” people to optIn such adherence to Koin API

[ianbrandt]

I was able to resolve the exposed API dependency issue via the non-propagating use approach, and by making my KoinComponent implementation internal:

@OptIn(KoinApiExtension::class)
internal class HelloApp : KoinComponent {

With @OptIn being experimental, I had to opt-in to it itself in my build:

kotlinOptions.freeCompilerArgs += "-Xopt-in=kotlin.RequiresOptIn"

[gps]

FWIW, i ended up using [module wide opt-ins](https://kotlinlang.org/docs/reference/opt-in-requirements.html#module-wide-opt-in) to more or less disable this warning. While i understand that it doesn’t make sense to implement KoinComponent frivolously, especially when there are extensions already available for “standard” use sites, for the codebase I’m working on, it looks like implementing KoinComponent really is the best option.