How to handle component dependencies?

[brahyam]

Thanks for your support and for maintaining the framework,

On a big scale project, how would you handle dependencies / dependency injection?

We have been exploring some approaches:

---

1. Lean: Not using any framework, instantiating all needed dependencies on native platforms and passing them to the root component on init and them to all components that need them:

Advantages:

• Explicit
• Compile time safe

Disadvantages:

• Makes root bloated
• All dependencies need to be instantiated before the app starts
• When the tree has many levels, dependencies need to be propagated through many levels before they can be used which bloats the whole tree
• When a leaf node has a new dependency all parents need to be modified to add it

---

2. Custom Component Context: Not using any framework, instantiating all needed dependencies on native platforms and embedding them into a custom component context:

Advantages:

• Compile time safe
• Unbloated component constructors

Disadvantages:

• Not explicit
• All dependencies need to be instantiated before the app starts

---

3. DI: Using a DI framework (Koin / Kodein / Service Locator)

Advantages:

• Unbloated component constructors
• Dependencies are instantiated just when needed

Disadvantages:

• Not compile time safe
• Requires extra tests setup

---

Concrete example 1:

Tracking. We need to be able to fire tracking events from almost all screens on the app. We plan on having a TrackingService class that has a method track and is used from multiple places to fire the events.

With approach 1 we will have a trackingService parameter on almost every component we create.

Approaches 2 and 3 seem cleaner.

Which would be the preferred way?

Concrete example 2:

Auth. Some parts of the app UI will have to logout the user. We plan to have an AuthService which exposes an observable authState:Flow<Boolean> and a method setAuthState(Boolean) to update it. AuthService will have one component listening to its authState and updating the tree accordingly (eg. to logged out / logged in components). Leaf UI components will call setAuthState whenever they need to modify the state.

With approach 2/3 all components will have access to it even if not needed.

Is a shared service the right approach?

[arkivanov]

Thanks for such a good question! First of all, personally I'm trying to avoid any DI frameworks. It might be opinionated, but I believe that DI frameworks hide the excessive complexity of the code. When I catch myself willing to add a DI framework, it is a sign for me that the code is coupled and complex.

A solution for this is usually to decompose the code by smaller peaces (e.g. modules). This is actually one of the primary purposes of Decompose!

So I would certainly go with the approach #1 or #2. I would pass all the dependencies via constructors. Except, probably, the cases with the most commonly used dependencies, like Tracker or HttpClient. Such common things I would likely add to the custom ComponentContext. Having a dependency in a constructor is perfect indicator that it is actually required by the sub-tree.

Also as a side note, using a DI framework doesn't necessarily mean not compile time safe. E.g. Dagger is compile time safe.

PS: I'm wondering how "Using a DI framework (Koin / Kodein / Service Locator)" would help to have "Unbloated component constructors"?

[brahyam]

Thank you for sharing.

With unbloated component constructors what I meant is

with approach 1, constructor increases size with every new service that it or its children uses:

ComponentImpl(
    componentContext,
    storeProvider,
    trackingService,
    authService,
    outputCallback,
    ...
): Component {
    private val store = instanceKeeper.getStore {
        ComponentStoreProvider(
            storeFactory,
            trackingService,
            authService
        ).provide()
    }
}

with approach 3 (eg using Koin DI ), we pull the services from DI:

ComponentImpl(
    componentContext,
    storeProvider
): Component, KoinComponent {
    private val store = instanceKeeper.getStore {
        ComponentStoreProvider(
            storeFactory = storeFactory,
            trackingService = get(), // <-- get() retrieves dependency from Koin module
            authService = get()
        ).provide()
    }
}

[arkivanov]

Thanks for the example! The second snippet doesn't look like dependency injection. Either things are just created inside the component, or taken from a global holder. In either case the same is possible without DI frameworks and without bloating the constructor. There should be no magic here.