Explore BindingContainer classes

[ZacSweers]

These would be analogous to how modules work in Dagger, but with a new annotation of @BindingContainer. Name suggestions welcome.

There are a few reasons, some more compelling than others. The main point though is that none of them work with interfaces only

1. Inferred graph validation for dynamic graphs. Something we can do in Metro in a way that was never possible in KSP/apt/guice. i.e. imagine you take in a vararg set of modules to a createGraph<AppGraph>() call and we can validate that those modules all add up correctly.
   • This is the most appealing one. You can also scale this up to do some neat things around anonymous injection, such as a test with injections. But that's a future idea/problem
   • You can also get module overrides in a way that doesn't violate graph validation, insofar as metro doesn't have to know about it
2. There are some things you can't or suck to do with just interfaces.
   • You can't replace a declared interface, so you have to rely on both prod/fake interfaces to both be contributed and either
     • The test contribution has to know about the prod one so it can replace it
     • The graph has to explicitly declare the exclude
   • You can't have stateful/conditional interfaces. NetworkModule(Endpoints.Internal) is frankly much simpler than either
     • Maintaining some qualified enum on the graph separately that's replaced/excluded through a wrapper class
     • Duplicating whatever provider(s) is using it
3. It does conflate "is this a graph" or "is this my dependency factory" all into one class in some cases

Metro basically already supports modules in how it generates code, and it'd limit/deemphasize how they could be used. They would only be providable via these specific creator functions at the moment, the biggest change is that we'd be doing validation at a different point in the compilation in that case. It won't be an initial release thing for sure as there's a bunch more considerations.

A dynamic graph creation would look something like this

val graph = createGraph<AppGraph>(
  NetworkBindings(Endpoint.Prod),
  AuthBindings(),
  // ...
)

This could also open some interesting opportunities for adhoc injection. Imagine a test with injection like so

class BugsnagTest {
  @Inject lateinit var bugsnagApi: BugsnagApi
  @Inject lateinit var server: MockBugsnagServer

  @Before
  fun setUp() {
    installMetroGraph(
      RealBugsnagClientBindings(
        BugsnagClientConfig(
          auth_token = MiskConfig.RealSecret("000a0000-a000-0000-000b-0cd00000000e"),
        )
      ),
      ServiceBindings<MockBugsnagServer>()
    )
  }
}

where installMetroGraph is defined like so

inline fun <reified T> T.installMetroGraph(vararg dependencies: MetroDependenyFactory): Unit = error("Implemented by the compiler")

The compiler plugin would then generate a synthetic @DependencyGraph declaration in the class during FIR and implement it in IR. Finally, during IR we would replace the installMetroGraph call to create the graph and call its generated injector for that class on that instance. Could probably even create a test runner that allows you to make these constructor injected

Notes

• We would need to heavily memoize these graph creations to avoid unnecessary validations
• We would need to defer validation somewhat (entirely?) to the graph creation call, which changes some assumptions of how we create binding graphs + validate + implement graphs today
• Should we limit this as an advanced use case?