Hey everyone. I was wondering how you guys organiz...

# koin

[s3rius]

Hey everyone. I was wondering how you guys organize various tiny dependencies that are sometimes needed for a class, in Koin Annotations.

For example, let's say there's an ApiClient class that needs a bunch of inputs. Basically like this:

@Single
class ApiClient(
    val baseUrl: String,
    val enableLogging: Boolean,
    val cacheDirectory: Path,
    val authClientId: String,
    ...
)

There are a few ways of providing these dependencies:

1. Tagging them all as ``@InjectedParam`` and doing a ``getApiClient { parametersOf(...) }`` once at the start of the app (to create the singleton). But this seems pretty shaky: it fails to work well with several parameters of the same type (such as ``baseUrl`` and ``authClientId``) and there's no compile-time safety.
2. Adding all those dependencies to Koins dependency graph via ``@Single`` or ``single()``, etc, using ``named<>`` to differentiate them. But that seems like you're polluting the dependency graph with dependencies that are really just details of a particular use-case.
3. Stuffing everything into a ``ApiClientConfig`` class and only providing that class?
4. Using ``@Property`` and providing everything as a properties map?
5. Not using Annotations for classes like this; instead injecting them via code in the main application where these various configurations/settings can be loaded?

I've tried a few different ways over the months but they all seem somewhat messy and dissatisfactory.

Any widsom to share? Preferable from larger codebases where this kind of mess might end up having a big impact on readability or reproducibility?

[arnaud.giuliani]

did you tried properties? there is @Property for that, and you can declare properties that you set into yoru definition

[s3rius]

Yes, properties are #4 on my list. It's something I'm considering, but I'm a bit unhappy about the lack of compile-time safety. As far as I see, if I change the name or the type of a property it's entirely on me to make sure I find all instances of where it is used.

[arnaud.giuliani]

yeah, properties are quite dynamic. can be loaded in many ways