I'm looking at the hilt cheat sheet, and I haven't had to add @Binds to a project yet. What's the us...

# dagger

[Colton Idle]

I'm looking at the hilt cheat sheet, and I haven't had to add @Binds to a project yet. What's the use case for it?

I have plenty of places in my code where I do:

@Provides
fun provideSomething(
    @ApplicationContext context: Context
): SomethingInterface {
    return SomethingActualImpl(context)
}

[Javier]

it should be a binds

[Javier]

just add a new parameter to the fun with the impl as a type

[Colton Idle]

But... it works without binds?

[Javier]

Yes, but binds is more efficient and semantically it is easier to know that a binds is when you are binding an interface with an implementation, and provides for rest.

[Arun]

Binds is better since it is used only at compile time to link implementation to interface. The module itself is not used in Dagger generated code, as dagger would generate the code for linking the two.
This means the module class can be fully removed by R8/Proguard on release builds.

When provides is used, Dagger generates code that will actually call the method you defined since it can't know what you are doing inside the method.

[Colton Idle]

That's super helpful. Thanks @Arun

[pollux-]

@Colton Idle Hope this would help
https://sreekumar-av.medium.com/kotlin-dagger-best-practices-966199b48b89

[Jeremy]

Is there practical difference between @Binds and static @Provides ?

[trevjones]

if you are using provides when a binds would work you run the chance of having people basically copy pasting the entire constructor arg list over. That can cause some pretty sad signal to noise ratio's for code reviewers.

[trevjones]

not always true, but that is exactly what is happening in colton's OP

[Jeremy]

I agree. @Binds forces dependencies to be public to other modules so sometimes its a tradeoff