Component dependencies and the gradle project dependency structure: can it be inverted?

[dimsuz]

Let's say I have two gradle modules: :app and :login. Each of them has a component.

When using Dagger I could have both of them defined as subcomponent and have login be child of the app like this:

// in module ":login"
@Subcomponent
interface LoginComponent {
  // ...
}

// in module ":app" which depends on ":login"
@Subcomponent
interface AppComponent {
  fun loginComponent(): LoginComponent
}

fun main() {
  val appComponent = DaggerAppComponent()
  val loginComponent = appComponent.loginComponent()
}

Notice that in this setup the :login module does not know anything about the :app module. Parent knows about child but not vice versa. LoginComponent even can be child of multiple parents.

It seems that I can't do this setup in kotlin-inject, because I have to provide parent as an argument to the child:

LoginComponent(parent = AppComponent())

and so gradle dependency is reverted too: :login must depend on :app now. This seems incorrect as each independent feature would now depend on the "app", it's as if List elements would know the collection they are in :)

I understand that this can be resolved by having AppComponent implement some kind of an interface, which is provided to the children and which could live in a different module, but this seems a bit tedious.

Did I miss something perhaps?

[evant]

An interface would be the suggested way to do this, yes.

// base module
interface AppComponent

// feature module
@Component abstract class LoginComponent(@Component val parent: AppComponent)

// app module
@Component abstract class AppComponentImpl : AppComponent

There's a few reasons it's done in this direction but the biggest on is it straight-forwardly maps to the generated code where LoginComponent needs to reference AppComponent in some way to grab dependencies.

It shouldn't be more tedious than any other cases where you define an interface in base for your features to use that's implemented in app?

[dimsuz]

I see, thank you. I'll try with interface then if this is the best option.

It shouldn't be more tedious than any other cases where you define an interface in base for your features to use that's implemented in app?

So far I've never defined an interface for features, because they were sort-of self contained and parent-child dependencies were resolved based on this "dagger way" of declaring a method on a parent component.

I'll try it the way you've suggested it may turn out ok.