That's rather a question than a bug.
Is there a written reasoning why Subcomponents were created and if we should better use them and not dependent components?
Dagger 2 introduced Subcomponents that facilitate using the parent's dependencies without a manual exposing of required dependencies. However, trying to apply it in a multi-module project we get dependency cycles (because the subcomponent needs to know about its parent) and the generated Component class includes all the generated subcomponents classes becoming a pretty massive thing over time.
Is there any reason why we should still try to stick with Subcomponents or is it totally fine to use Component Dependencies? Is there a chance that the latter will be deprecated in the next Dagger updates?
You seem to have answered the first part of the question yourself.
On Tue, Dec 18, 2018, 10:36 AM Artur Badretdinov <[email protected]
wrote:
That's rather a question than a bug.
Is there a written reasoning why Subcomponents were created and if we
should better use them and not dependent components?Dagger 2 introduced Subcomponents that facilitate using the parent's
dependencies without a manual exposing of required dependencies. However,
trying to apply it in a multi-module project we get dependency cycles
(because the subcomponent needs to know about its parent) and the generated
Component class includes all the generated subcomponents classes becoming a
pretty massive thing over time.Is there any reason why we should still try to stick with Subcomponents or
is it totally fine to use Component Dependencies? Is there a chance that
the latter will be deprecated in the next Dagger updates?—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/dagger/issues/1364, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEfkCtGg3IcpB_prZQVU7eHq7xMYNks5u6QuZgaJpZM4ZYiq4
.
Thank you. Could you please share your opinion on the second part?
Subcomponents only make sense inside a single module, yes.
On Tue, Dec 18, 2018, 12:06 PM Artur Badretdinov <[email protected]
wrote:
Thank you. Could you please share your opinion on the second part?
—
You are receiving this because you commented.Reply to this email directly, view it on GitHub
https://github.com/google/dagger/issues/1364#issuecomment-448295192, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEEEWhOXd-2xc57BQ4PQ8VOODxM1Pvtks5u6SCtgaJpZM4ZYiq4
.
@Module.subcomponents was introduced in part to help break this build cycle. It allows you to inject the subcomponent builder without ever referring to the owning component. dagger.android takes heavy advantage of this.
You don't have to be worried about either API going away.
Subcomponents have the convenient benefit of sharing _all_ bindings with their parent component. Component dependencies can't do that, they only share the bindings exposed as entry point methods. Some people find it tedious to expose every binding they want just so that the "child component" can use it and subcomponents alleviate that. It's a matter of style.
Most helpful comment
@Module.subcomponentswas introduced in part to help break this build cycle. It allows you to inject the subcomponent builder without ever referring to the owning component.dagger.androidtakes heavy advantage of this.You don't have to be worried about either API going away.
Subcomponents have the convenient benefit of sharing _all_ bindings with their parent component. Component dependencies can't do that, they only share the bindings exposed as entry point methods. Some people find it tedious to expose every binding they want just so that the "child component" can use it and subcomponents alleviate that. It's a matter of style.