Auto-generate components and more

[JavierSegoviaCordoba]

I would like to extend the @dave08 idea combined with what are doing other libraries like PopKorn or this Hilt library.

Summary

1. Auto-generate components based on some annotation or multiple annotations.
2. Create a specific Android module that helps with the ViewModel injection.
3. Create a specific module that provides an opinionated bundle of components for popular platforms like Hilt does in Android (at least the Android one, maybe in the future, another one for Desktop and iOS). Not sure if Compose framework used in multiple platforms could share similar components.

1. Auto-generate components based on some annotation.

Similar to PopKorn or the Hilt library I mentioned before, they avoid the creation of components or modules. An example is better to explain that.

interface UsersRepo { ... }

// PopKorn
@Injectable
class UsersRepoImpl(private val usersService: UsersService) : UsersRepo  { ... }

// Hilt
@Bound(component = SingletonComponent::class)
class UsersRepoImpl @Inject constructor(private val usersService: UsersService) : UsersRepo 

And that's it. No modules, no components.

I don't know if this magic can be done with the same exact annotations that currently exist (Inject, Provides, and so on). Probably for a simple setup it is possible but for a difficult setup, no. For example, multiple inherency, and so on.

For the basic use case, based on Inject and Provides, I would like to suggest:

interface UsersRepo { ... }

@Inject
class UsersRepoImpl(private val usersService: UsersService) : UsersRepo  { ... }

And, if possible, for providing third-party dependencies I would use top-level functions:

interface UsersRepo { ... }

@Provides
fun provideRetrofit(): Retrofit = buildRetrofit()

@Provides
fun provideUsersService(retrofit: Retrofit): UsersService = buildUsersService(retrofit)

@Inject
class UsersRepoImpl(private val usersService: UsersService) : UsersRepo  { ... }

Under the hood, kotlin-inject will generate the components. Because kotlin-inject doesn't provide components, we should create empty interfaces, for example, as Hilt does, we can have:

interface SingletonComponent

interface UsersRepo { ... }

@Provides(SingletonComponent::class)
fun provideRetrofit(): Retrofit = buildRetrofit()

@Provides(SingletonComponent::class)
fun provideUsersService(retrofit: Retrofit): UsersService = buildUsersService(retrofit)

@Inject(SingletonComponent::class)
class UsersRepoImpl(private val usersService: UsersService) : UsersRepo  { ... }

Because KMP is coming soon, custom annotations are going to be necessary (I don't know what are the plans for KMP, maybe expect/actual using javax Inject annotation in the JVM part, but for this idea, it is necessary to add more annotations and Inject will not be enough.

2. Create a specific Android module that helps with the ViewModel injection.

A pluggable solution to injecting ViewModel should be great (maybe with Compose this becomes useless, but maybe adding support to scoping to the Navigation library as Hilt does could be great too).

3. Create a specific module that provides an opinionated bundle of components for popular platforms like Hilt does in Android.

I think it is self-explanatory, the previous approaches let you focus on injecting dependencies and not on how to deal with the DI framework, so this is the last thing to just inject dependencies and doing no more things.

I think Android should be easy in the way it is possible to just copy the Hilt behavior, but I would like to see this feature in the future in other frameworks like desktop JVM apps, native apps (iOS, macOS...), and so on.

[evant]

Been thinking more about moving @Provides out of components and I think I may have a workable solution. The key would be changing the meaning of @Scope annotations. Right now they define which component retains them, but what if they only defined where a provides could be used instead? This way you could do:

@Provides
@AppScope
fun apiService(): ApiService = ...

...

@Provides
@TestScope
fun testApiService(): ApiService = ...

...

@AppScope
@Component
interface AppComponent {
   val main: Main // can only access @AppScope provides
}

@TestScope
@Component
interface TestComponent {
   val main: Main // can only access @TestScope provides
}

an unscoped @Provides could be used an any component, much like an unscoped @Inject.

There would then be a separate annotation to make the component retain the instance:

@Provides
@AppScope
@Retain
fun json(): Json = ...

In theory this would be enough to not even have provides defined inside a component.

Pros

• Components are now quite simple, only defining what instances you can obtain, not how to get them.
• It's easy to modularize providing dependencies as all you need is a reference to the scope annotation.
• There's a nice mirroring between @Inject and @Provides.

Cons

• Namespace pollution: it will be quite easy to call these provides methods manually from anywhere because they aren't contained in anything.
• How do providing instances work? Right now you can pass instances by using constructor args of the component. Do we still want to keep that somehow? Will have to explore how this effects testing patterns as it's particularly useful to provide instances of dependencies for specific tests.

Open Questions

• How does this effect processor performance? Right now it walks up the components to find all provides, it would have to visit all @Provides annotations instead, which potentially means more AST scanning.
• What does it mean to @Retain without a scope? Is this something we'd even want to support?
• What does this mean for javax compatibility? We are changing the meaning of scope which could cause confusion. Particularly if you were to use the built-in @Singleton scope.
• Naming: @Scope and/or @Retain could be called something else?

[evant]

Unfortunately after looking into it I don't think there's a good way to get it to work. The problem is you can't easily find top-level @Provides because you can't quickly look up functions which have a certain return type. You'd have to scan not only the current module but all of it's dependencies looking for them which is a show-stopper imo.