-
Notifications
You must be signed in to change notification settings - Fork 55
Split generated AssistedInject_*Module to multiple modules #87
Comments
How do we know which bindings are semantically grouped together? |
I was initially thinking that splitting the generated module to one module per factory would be an option, but actually it's not that different than just setting up the bindings manually :/ |
It's actually worse because with your own modules you could at least group
them
…On Wed, Mar 20, 2019 at 5:31 PM Nimrod Dayan ***@***.***> wrote:
I was initially thinking that splitting the generated module to one module
per factory would be an option, but actually it's not that different than
just setting up the bindings manually :/
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#87 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEEEbzgtDnbwT_zALSrupmgcX2kpBGqks5vYqjHgaJpZM4b4Esm>
.
|
Could we have the @AssistedInject.Factory take some sort of user-defined @AssistedGrouping annotation (somewhat conceptually like the @mapkey stuff in dagger) that the @AssistedModule would use in its creation? |
Today you can choose not to use Ideally the |
Well the issue is still the extra boilerplate creation (which is why @AssistedModule even exists, I assume.) It'd be nice to not have to write those extra binds for every factory. |
@Nimrodda google/dagger#1781 might be related to your problem. Re-including the assisted module in the subcomponents will let the assisted module search the subcomponent for provisions (in your case Feels unintuitive to reinclude a module in a subcomponent, but it definitely solves the need for splitting the AssistedInject module into multiple modules. |
Could you please elaborate on that? |
Here's another example to be more specific:
There's two things happening here.
|
@davidliu my use case is a little bit more complicated. Here is an example of what I mean: That's what I want (and as far I understand it's not possible with a single AssistedModule): Is there a way to make it work still? |
Like I mentioned, the AssistedModule doesn't impose a dependency requirement. You can put it in each of your components, and it will be fine. Declaring the AssistedModule in your app component won't require you to have the MainRepo at the app level; you just also need to have the AssistedModule at the MainActivity level. Just try it out in code instead of trying to figure it out beforehand. I'm not sure how to be any more clear in my explanation so I just made an example project for this: |
@davidliu thank you for the answer and for the example. Your repo was extremely helpful! |
Using the AssistedInject_AssistedModule approach worked like a charm. |
Just to leave the note that for Dagger users the latest version (2.31) has Assisted injection included, so this problem no longer exists (I solved it by removing this dependency). |
Yep. Realistically, we never were going to fix this. The correct fix is to either allow Dagger to automatically discover modules or to fully upstream the assisted feature. The latter happened. |
Currently the generated AssistedInject_*Module contains all the bindings for
@AssistedInject.Factory
annotated factories in one module. As a result, it's impossible to have dependencies that exist only in subcomponents. For example:I have two ViewModels, where one of them takes an argument (
GithubApi
in this case), which exists only in one the subcomponent hosting these view models.The generated
AssistedInject_ViewModelAssistedFactoriesModule
contains the bindings for both factories above. Due to that, I have to include it in theApplicationComponent
so it's visible to my subcomponents. But then compilation fails sinceGithubApi
's binding is only defined in one of the subcomponents.The text was updated successfully, but these errors were encountered: