What exactly do you mean by component to component deps

Question

David · Answer

good talk by the designer s on this point <https www youtube com watch v=PBrhRvhF00k>

Paul Woitaschek · Answer

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

Paul Woitaschek · Answer

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

Paul Woitaschek · Answer

< David> ^

David · Answer

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

David · Answer

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

David · Answer

I suspect you are going to say analytics retrofit okhttp and many other true read only singletons

David · Answer

which currently are being scoped by the parent app module via an annotation like ` ApplicationScope` or ` Singleton`

David · Answer

drum with drumsticks

Paul Woitaschek · Answer

gt I suspect you are going to say analytics retrofit okhttp and many other true read only singletons

Paul Woitaschek · Answer

Yes exactly this

David · Answer

tehehe almost as if I ve had the same pain

David · Answer

so we are modularising differently

David · Answer

Let me get a pic of my app

David · Answer

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>

David · Answer

the key thing is that app is the top

David · Answer

in your instance app is the bottom

David · Answer

both are valid AFAICT as ways to start down the modularisation path

David · Answer

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 amp 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

Paul Woitaschek · Answer

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

David · Answer

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

David · Answer

I can share my repo if you d pass on your git username and promise not to steal my deploy keys joy