Hi everyone, I'm using Koin with Ktor, and previou...
# koin
g
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!
a
KoinComponent
is to help you extend Koin API where there is not already extension for your classes
it should be a injection configuration stuff for your app
g
hmm, so it sounds like implementing
KoinComponent
may indeed be the right thing to do?
consider an example like this:
Copy code
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)
    }
}
would that be the right way to be able to use
inject
from
Foo
?
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)
a
yes the
OptIn
is the way to go to assume your usage of KoinComponent
👍 1
try constructor injection as much as possible
👍 1
i
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.
👍 1
a
Interesting point. The thing is
KoinComponent
is a way to bootstrap Koin where we don’t already have any extensions.
behind that I’ve seen many abuse of such interface. Then I “push” people to optIn such adherence to Koin API
i
I was able to resolve the exposed API dependency issue via the non-propagating use approach, and by making my
KoinComponent
implementation internal:
Copy code
@OptIn(KoinApiExtension::class)
internal class HelloApp : KoinComponent {
With
@OptIn
being experimental, I had to opt-in to it itself in my build:
Copy code
kotlinOptions.freeCompilerArgs += "-Xopt-in=kotlin.RequiresOptIn"
g
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.