What exactly do you mean by "component-to-component deps"?

# dagger

[Paul Woitaschek]

What exactly do you mean by "component-to-component deps"?

[David]

good talk by the designer(s) on this point:

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

[Paul Woitaschek]

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]

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]

@David ^

[David]

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]

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]

I suspect you are going to say analytics, retrofit, okhttp and many other “true” read-only singletons.

[David]

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

[David]

🥁

[Paul Woitaschek]

I suspect you are going to say analytics, retrofit, okhttp and many other “true” read-only singletons.

[Paul Woitaschek]

Yes, exactly this

[David]

tehehe… almost as if I’ve had the same pain

[David]

so, we are modularising “differently”

[David]

Let me get a pic of my app

[David]

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]

the key thing is that “app” is the “top”

[David]

in your instance “app” is the bottom

[David]

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

[David]

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.

[Paul Woitaschek]

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]

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

[David]

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