afollestad / ulfberht

🗡️ A small but powerful & opinionated DI library. Written in Kotlin, and powered by annotation processing.

Hey, I'm Aidan 👋

I'm currently a Staff L6 Android (and part time iOS) Engineer @ Square.

Check out my website, Threads, and Instagram!

ulfberht's Issues

Child components should be assigned from parents

Instead of:

@Component
interface Parent

@Component(parent = Parent::class)
interface Child

It's more maintainable and searchable to have:

@Component(
  children = [Child::class]
)
interface Parent

@Component
interface Child

Provider<> injection

Injecting the internal Provider<> interface for a given type should be supported like it is for Dagger.

Improve @Provides circular dependency detection

Below, SomeClass<String, Boolean> includes OneImpl in its @Provides method. OneImpl injects SomeClass<String, Boolean> into its constructor.

@Module
interface MyModule1 {
  @Binds fun one(one: OneImpl): One

  @Binds fun two(two: TwoImpl): Two
}

@Module
abstract class MyModule2 {
  @Provides fun one(one: OneImpl): SomeClass<String, Boolean> = SomeClass("test", true)

  @Provides fun two(two: TwoImpl): SomeClass<Int, Long> = SomeClass(6, 10L)
}

interface One {
  fun doSomething()
}

class OneImpl(
  private val two: Two,
  private val idk: SomeClass<String, Boolean>
) : One {
  override fun doSomething() = two.doSomething()
}

Use annotations for qualifiers instead of named params?

Still exploring if this is what I'd want the experience to be.

Constructor Injection

This is an issue to request for direct constructor injection.
Currently the @Inject functionality cannot be used on the constructor of a class.

Current behaviour:

data class DependencyA

data class MyClass constructors (
     val dependencyA: DependencyA
)

@Module
abstract class DependencyProvider {
     @Provides
     fun provideMyClass(dependencyA: DependencyA) = MyClass(dependencyA)
}

Expected behaviour:

data class MyClass @Inject constructor (
     dependencyA: DependencyA
)

Compile time safety

Verify that all dependencies are satisfied at compile time

@IntoSet capabilities

A simple case:

@Module
abstract class MyModule1 {
  @Provides @IntoSet 
  fun stringOne(): String = "hello"
}

@Module
abstract class MyModule2 {
  @Provides @IntoSet 
  fun stringTwo(): String = "world!"
}

...

@Inject lateinit var strings: Set<String> // ["hello", "world!"]

---

A qualified case:

@Module
abstract class MyModule1 {
  @Provides @IntoSet @HelloWorld
  fun stringOne(): String = "hello"
}

@Module
abstract class MyModule2 {
  @Provides @IntoSet @HelloWorld
  fun stringTwo(): String = "world!"
}

...

@Inject @HelloWorld lateinit var strings: Set<String>
@Inject @HelloWorld lateinit var providedStrings: Set<Provider<String>>
@Inject @HelloWorld lateinit var providedStrings: Provider<Set<String>>
@Inject @HelloWorld lateinit var providedStrings: Provider<Set<Provider<String>>>

Android ViewModel injection

When view model types are injected, they should be associated with a view model factory for the injector.

Incremental Processing

Make the processor incremental.

Multi-module dependency injection

I have seen that currently, Google provides us with the dynamic feature module to separate features in separate modules. Will this library support multi-module dependency injection?

Circular dependency detection

Circular dependency detection is needed, with build-time error messaging.

---

interface One
class OneImpl(val two: Two) : One

interface Two
class TwoImpl(val one: One) : Two

When we get One, we have to get Two. When we get Two, we have to get One. This creates a paradoxical loop.

One -> Two -> One -> Two -> ...

---

1. Through @Binds

@Module
interface SomeModule {
   @Binds fun bindOne(impl: OneImpl): One

   @Binds fun bindTwo(impl: TwoImpl): Two
}

ModuleBuilder should detect this by looking at the constructors of OneImpl and TwoImpl, comparing parameter types recursively.

2. Through @Provides

@Module
abstract class SomeModule {
   @Provides fun provideOne(two: Two): One = OneImpl(two)

   @Provides fun provideTwo(one: One): Two = TwoImpl(one)
}

ModuleBuilder should detect this by simply looking at the parameters of each provide method and comparing recursively.

---

Comparing recursively above can be important for situations like this:

interface One
class OneImpl(val two: Two) : One

interface Two
class TwoImpl(val three: Three) : Two

interface Three
class ThreeImpl(val one: One) : Two

One -> Two -> Three -> One -> Two -> Three -> ...

Kotlin Native support

Is there anything stopping this library from supporting native targets? It would be cool to have true dependency injection support on native. Currently, the only di library for native targets is Kodein and that is service lookup library and not true di.

Allow abstract classes to have @Binds functions

@IntoMap capabilities

A simple case:

@Module
abstract class MyModule1 {
  @Provides @IntoMap("one") 
  fun stringOne(): String = "hello, "
}

@Module
abstract class MyModule2 {
  @Provides @IntoMap("two")
  fun stringTwo(): String = "world!"
}

...

@Inject lateinit var strings: Map<String, String> // ["one": "hello, ", "two": "world!"]

---

A qualified case:

@Module
abstract class MyModule1 {
  @Provides @IntoMap("test", "one") 
  fun stringOne(): String = "hello, "
}

@Module
abstract class MyModule2 {
  @Provides @IntoMap("test", "two") 
  fun stringTwo(): String = "world!"
}

...

@Inject("test") lateinit var strings: Map<String, String> // ["one": "hello, ", "two": "world!"]

Upgrade generics support

Take this module:

@Module
abstract class Module {
  @Provides fun someClass1(): SomeClass<String, Boolean>

  @Provides fun someClass2(): SomeClass<Int, Long>
}

The generated code should be able to differentiate between these two return types and inject them correctly.

Unit test the processor

Add plugin capabilities

Android logic, like lifecycles and view models, should not be in the core/processor modules. The processor should be able to find plugins by an annotation and pull out logic.