Dagger: Feature Request: Allow defining parent of built in components

[digitalbuddha]

Hi folks, thank you for Hilt, particularly the documentation. I had a feature request/question. Is there any reason why @DefineComponent allows declaring the parent component but the built in components do not? Ideally I'd like to do the following:

Declare a UserComponent as a child of ApplicationComponent
Declare ActivityComponent to be the child of UserComponent

From what I gather this means I'd need to maintain the Manager around the UserComponent as well as any Activity/Fragment components that I create. I'd like to delegate to ActivityComponentManager and FragmentComponentManager.

Thank you kindly, I'm sure there is a reason why this does not work out of the box

[digitalbuddha]

I made a minimal sample of what I think it takes to create a user scope.
https://gist.github.com/digitalbuddha/4c63034969c107af3c98e098ae5ffbe7

[Chang-Eric]

So there are a few technical challenges that make this difficult to support.

The first is that custom components inserted in the tree are very likely to have arguments that need to be passed to the component builder. In your case, this would be the user id. The issue here is that because Hilt creates your components for you, we would have to figure out a way to get those arguments at the right time.

There’s also a question of storing the components we created for you. For example, is your inserted component one instance for the application or one instance per activity (or something else like one instance per user id?) Because Hilt hides the components, adding in hooks to control this would be complicated.

Finally, there’s a question of compatibility with extensions/libraries. For example, there are two basic paths for the activity component. The first is using the same dagger.hilt.android.components.ActivityComponent and just changing the parent somehow. That is difficult though because even ignoring the fact that the parent is statically defined, what does this mean for a library using @AndroidEntryPoint that your app uses. Do they suddenly become injected from the user component as well? It likely isn’t always safe to make a library activity account-aware as maybe it could access account data in a way that isn’t apparent. The alternative is only your @AndroidEntryPoint activities you declare are injected from your ActivityUserComponent (like you defined in your example). But that also has problems because now things like the ViewModel extension don’t work because they installed bindings in the standard Hilt ActivityComponent.

Anyway, I guess that is kind of a long way to say that supporting this would be very hard.

[digitalbuddha]

Thank you for explaining. The difficulty of the problem is one of the reasons I think it should be a base experience. Even if it is a single account/user scope similar to the retained activity scope. Thank you for verifying the gaps I had in knowledge

[Chang-Eric]

I think adding a built-in account component would be tough because there's a lot of stuff that goes into managing accounts that I think starts to get out of the scope of Dagger. For example, for an account component to make sense you'd need something managing the lifetimes of those components which starts to get into tricky questions like how are account switches handled with respect to the activity lifetime, etc.

There's also issues of if the AccountComponent is a parent of say the Activity, then it suddenly requires people to think about/handle accounts immediately when using Hilt even if their app doesn't have accounts.

With that said, I'm going to try to add some more docs to the site on this topic because it is a complex topic and one that is likely to come up for many people. Hope this all helps.