New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Finding the paths to DAG roots for a given binding #287
Comments
We have actually built the beginnings of similar features within Google built by users from various contributing projects. Nothing is even quite half-baked yet, but the ideas are promising. This will make a good tracking bug though and as soon as we have something worth sharing, we'll do it here. |
@gk5885 This is most requested feature of Dagger. Are are planning to release some kinda tool soon ? |
@ajaysaini-sgvu , vote. When I started learning the dagger I was completely confused by how the object graph looks. From my point of view, it's really none obviously. All the properties like Module(includes, subcomponents), Component(models) bring more difficulties. But it's not the only difficulty. For example, I don't understand, why subcomponents are declared in the module? Where I should use Component(dependencies={...}), what the difference between if I will do Module(include=A) and Component(dependencies=A) or if I will add both and so on.? |
I've recently started thinking about this as a feature similar to Rough examples: @dagger.query.Query(com.example.ComponentInterface.class)
interface WhyDoesThisComponentIncludeThisModule {
@AllPaths
void pathsTo(DeeplyIncludedModule m);
}
@dagger.query.Query(com.example.ModuleA.class)
interface WhyDoesModuleAIncludeModuleB {
@AllPaths
void pathsTo(ModuleB moduleB);
}
@dagger.query.Query(com.example.ComponentInterface.class)
interface WhatBindingsAreResolvedForTheDependenciesOfAParticularBinding {
@ResolvedDependencies
void resolvedDependencies(@SomeQualifier SomeKey key);
}
@dagger.query.Query(com.example.ComponentInterface.class)
interface WhoDependsOnThisBinding {
@DependentsOf // or @ReverseDependencies to match bazel query :)
void whoDependsOn(@SomeQualifier SomeKey key);
}
@dagger.query.Query(com.example.ComponentInterface.class)
interface DoesThisBindingTransitivelyDependOnAnotherBinding {
@SomePath
SourceKey somePathTo(@SomeQualifier TargetKey target);
}
@dagger.query.Query(com.example.ComponentInterface.class)
interface DoesAnyoneBindAQualifiedVersionOfFoo {
@SomePath
void qualifiedFoos(@dagger.query.AnyQualifier Foo qualifiedFoos);
}
@dagger.query.Query(com.example.ComponentInterface.class)
interface WhatTransitiveDependenciesOfFooAreScoped {
@SomePath
void scopedTransitiveDependencies(@dagger.query.AnyScope Foo qualifiedFoos);
@SomePath
void reusableTransitiveDependencies(@Reusable AnyScope Foo qualifiedFoos);
} |
This isn't a feature core to Dagger2, but a tool that we could build on top.
I want a tool that can answer the question: "who needs this binding", recursively, similar to the IDE shortcut "call hierarchy" (ctrl+option+H) on methods.
Today, I can find the answer to that question by doing "find usages", and then for each usage I can do it again, etc etc. Doable, but not practical.
What I want instead is a tool (maybe eventually an IDE plugin) that given a type A, will give me the chain
MyComponent.someMethod() > Module.someBinding() > SomeManager > A
whereA
is a binding used bySomeManager
.To do that, we just need a representation of the whole graph, starting from the roots. If Dagger could output the whole graph for a given component in some way, we could then build that.
Another option would be to build something independent that starts from component interfaces and rebuilds the whole graph. But I'm not super excited at the idea of redoing what Dagger2 does.
The text was updated successfully, but these errors were encountered: