https://kotlinlang.org logo
#dagger
Title
p

Paul Woitaschek

11/19/2018, 5:27 PM
What exactly do you mean by "component-to-component deps"?
d

David

11/20/2018, 5:46 PM
good talk by the designer(s) on this point:

https://www.youtube.com/watch?v=PBrhRvhF00k

p

Paul Woitaschek

11/21/2018, 2:02 PM
Still struggling. I often have a circular dependency problem. Let's say I have this recipe feature where I display recipes and a
RecipeComponent
. Now this recipe component needs to depend on dependencies from my
AppComponent
. So far - fine, no problems. Now in my App I want to show a
RecipeOverviewFragment
, so my app needs to have a dependency on the
recipe
dagger module. How do you overcome this circularity?
My workaround is to let tze
RecipeComponent
not depend on the
AppComponent
but rather expose all it's dependencies through a `bindsInstance' method. But there are like 10 of them so this scales not too well.
@David ^
d

David

11/21/2018, 2:22 PM
i see. So yes, in the configurations where i modularise “child” modules such as your recipe feature do not depend on parent modules. They aren’t `subcomponent`s but rather self-contained “mini apps” that given a wrapper (something that bundles an APK) can be launched by themselves. That’s not to say they don’t have dependencies in order to launch (the
@BindsInstance
you allude to) but in the cases where I am modularising I am never binding anything more than
Context
to a child module as part of the
@dagger.Component
construction.
So, I suppose my natural questions are… 1) What is the “AppComponent” providing that the child needs? 2) Can the provisioning of this be moved lower in the graph so that both the
app
and
recipe
(gradle) modules have a dependency on the this base component?
I suspect you are going to say analytics, retrofit, okhttp and many other “true” read-only singletons.
which currently are being scoped by the parent app module via an annotation like
@ApplicationScope
or `@Singleton`….
🥁
p

Paul Woitaschek

11/21/2018, 2:30 PM
I suspect you are going to say analytics, retrofit, okhttp and many other “true” read-only singletons.
Yes, exactly this
d

David

11/21/2018, 2:31 PM
tehehe… almost as if I’ve had the same pain
so, we are modularising “differently”
Let me get a pic of my app
I used degraph to generate this. Perhaps a prettier view is like using jw’s depenedency crawler like so; https://twitter.com/BrantApps/status/1041481094854524929
the key thing is that “app” is the “top”
in your instance “app” is the bottom
both are valid AFAICT as ways to start down the modularisation path
however, in my experience if you “push up” (i.e. give
recipe
a dependency on
app
) then you’d need to work as subcomponents do. If on the other hand you “push down” (notice ‘dumb’ modules that contain POJO & POKOS in
:model
and
analytics
in particular are right at the bottom of the graph) then you can use the
@dagger.Component
construct to control what is exposed to consumer modules.
p

Paul Woitaschek

11/21/2018, 2:43 PM
But what is the solution now? How can I have independent dumb modules that dependencies like a singleton retrofit instance but also have stuff like Fragments which need to be consumed?
d

David

11/21/2018, 2:49 PM
I must admit, the advice at this juncture is wholly opinion based. I’ve found the push down route to be a purer take on modularisation (each module being self-launch-able) but many have disagreed with me since it reduces the utility of Dagger’s scoping mechanisms. I’ve not found a definitive answer: https://github.com/google/dagger/issues/1075 https://github.com/google/dagger/issues/636
I can share my repo if you’d pass on your git username and promise not to steal my deploy keys 😂