Paul Woitaschek

    Paul Woitaschek

    3 years ago
    What exactly do you mean by "component-to-component deps"?
    d

    David

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

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

    Paul Woitaschek

    Paul Woitaschek

    3 years ago
    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

    3 years ago
    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 subcomponents 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….
    🥁
    Paul Woitaschek

    Paul Woitaschek

    3 years ago
    I suspect you are going to say analytics, retrofit, okhttp and many other “true” read-only singletons.
    Yes, exactly this
    d

    David

    3 years ago
    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.
    Paul Woitaschek

    Paul Woitaschek

    3 years ago
    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

    3 years ago
    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 😂