Alternative to Dagger's @Component.Builder

[kevinguitar]

Hello Zac 👋

I found out that there is no equivalent to Dagger's @Component.Builder in metro (written here), and we're using it to replace dependencies in our UI tests dynamically.

Is there an alternative to Component Builder, perhaps some ways to workaround it? (Contribution replacement doesn't work for our case because we need to specify impls and build the graph dynamically per test case)

[kevinguitar]

I think an example would give better context, with Dagger, we can override some bindings per test case by using builder functions in Component:

interface Logger {
  fun log(message: String)
}

@Inject
class LoggerImpl : Logger {
  override fun log(message: String) = println(message)
}

@ContributesBinding(AppScope::class)
interface LoggerModule {
  @Binds
  fun bindLogger(impl: LoggerImpl): Logger
}

In tests

@MergeComponent(AppScope::class)
interface TestAppComponent {

  @MergeComponent.Builder
  interface Builder {
    fun add(loggerModule: LoggerModule): Builder
    // other functions to override modules...
    fun build(): TestAppComponent
  }
}

class MyTest {
  @Test
  fun testWithFakeLogger() {
    val fakeLoggerModule = object : LoggerModule {
      @Binds
      override fun bindLogger(impl: FakeLogger): Logger
    }
    
    val testApp = DaggerTestAppComponent.builder()
      .add(fakeLoggerModule)
      .build()
    // ...
  }
}

[ZacSweers]

Builders aren't supported currently, nor are modules (the primary reason to have them). You could probably get decently far with replaces and @Includes, but builders haven't been a case I've prioritized. I'd recommend trying that first and see if you can't get far enough with them

[kevinguitar]

I spent a bit time today trying to fulfill our use case with replaces but soon realized that it's probably not a viable path. The main difference between Component Builder and replaces is runtime v.s. compile-time replacing, our UI tests highly rely on runtime replacing.

I'll try and see what else we can do here then, probably with @Includes 👍 Thanks!

[ZacSweers]

Sounds good. I'm open to builders, it's just going to be a bit of a heavy left. The biggest differences in terms of includes vs real modules is there's no way to indicate scoping (they'll be called every time) and includes functions obviously cannot have dependencies

[kevinguitar]

Looks like I managed to rework the component builder in a way that we can stub the real implementation in runtime, yet to test it coz ran into other blockers, but it should work.

Sharing the approach in case if it will be useful for anyone.

interface Logger {
  fun log(message: String)
}

@Inject
@ContributesBinding(AppScope::class)
class LoggerImpl : Logger {
  override fun log(message: String) = println(message)
}

Test code

@Inject
@SingleIn(AppScope::class)
@ContributesBinding(AppScope::class, replaces = [LoggerImpl::class])
class FakeLogger(
  private val real: LoggerImpl
) : Logger {

  var fake: Logger? = null

  override fun log(message: String) {
    fake?.log(message) ?: real.log(message)
  }
}

The nuance here is that the fake needs to be set after AppGraph is created, unlike the component builder which happens during AppGraph creation.