Dagger: Outputting a visual graph of the component hierarchy

[pyricau]

We have a huge component hierarchy, with many levels of subcomponents as well as "parallel" components (ie a dev component that extends the app component and replaces it, so it has all the same bindings / component hierarchy plus some dev bindings).

Our component hierarchy map to regions of the app (e.g. App scope > LoggedIn scope > Settings scope > Printer Settings scope > Add New Printer scope) so this would give us a nice graph of how the app is structured.

Dagger1 used to output .dot files for bindings, which was fun but not practical (too many bindings). It would be great if Dagger2 could output a .dot file mapping the component hierarchy, or some other format.

[gk5885]

This is actually along the same lines as #287 (which I'm sure is why you filed them together).

I don't think that it is likely that Dagger 2 will output .dot files as we have found them to be generally pretty crappy -- they display information in a useful format for too small of a subset of graphs. Particularly if you have a huge component hierarchy, static .dot files seem to fall pretty flat rather than being a useful way to present graphs.

The general strategy is likely to be to produce some sort of structured output that can be processed both to answers questions like those posed in #287 or to produce a visual representation. Particularly, something navigable built with d3 (or a similar library) that can process the structured data and provide good search capabilites has been prototyped and shows some promise.

[pyricau]

Cool! Yes, it's similar. #287 is more about answering a specific question at one point in time, this one is more about getting an overview of how things are architectured.

[ZacSweers]

@gk5885 anything you guys could share about your research so far? If you give some guidance around what you want it to look like, contributors could help.

[ZacSweers]

Ping on the above ^^. Would really like to help with this if possible.

[ronshapiro]

@netdpb has been working on some things to make this a lot easier, but we're still stuck at the "how to make this look pretty" phase. Can anyone enlist some designers/front-end-devs/visual-folks that might have an idea? Someone with d3 experience is likely to come up with something significantly better than us, and we're happy to accept contributions for this (or help on the dagger output side to assist them).

[mr-archano]

@ronshapiro maybe you could start sharing some data representation of a non-trivial graph - no matter how ugly it is - to let people to get an idea of the complexity of the data. In alternative having a gist of the code you're using to visit the graph would be appreciated.

[ZacSweers]

Could you maybe provide some details on what the output data would look like? Or better get, could the data be exportable in some agnostic format that could be parsed and presented in different ways? This would take some of the presentation burden off you guys, while keeping it flexible for others to consume and graph however they want. Community can also contribute new approaches in the future.

[ZacSweers]

I personally wouldn't mind just getting a giant JSON dump of everything you know about the graph and letting us parse it however. Even just a simple branch representation from the root would go a long way for us, then we could improve from there. Then again, we aren't using Binds or much of the other newer stuff yet

[pyricau]

@ronshapiro Can you elaborate why making it pretty is a blocker? I think the most important part is actually to open up the data. That way we can all start playing with it, learn what type of things are interesting to display and how, and then build that in Dagger or on top of it.

[ronshapiro]

It's not a blocker - our blocker is on releasing the infrastructure to make this easier. The point I was trying to make was that once this infra is checked in, getting it in any format should be relatively trivial.

If you want the data now, you can definitely fork the library and output the BindingGraph objects we create using the Filer pretty easily right now.

[ZacSweers]

poke

[ajaysaini-sgvu]

+1

[netdpb]

As Ron said, we are working on something that will let you inspect the binding graph, and even add validation rules at compile time. It's not nearly ready, and probably won't hit until next quarter.

[dvdciri]

Maybe worth checking this out https://github.com/dvdciri/daggraph, it's not perfect at this stage, but at least is giving some highlights of the general dependency graph.

[ronshapiro]

That seems to make a lot of naming assumptions - I think once we get the SPI finished, exporting the data into those visualizations looks awesome

[dvdciri]

Yeah, the assumptions that is based on are all the dagger related keywords i.e. @ Component, @ Module etc, which are mandatory also for dagger to recognize them. It has been built in a way that the rendering bit is separated from the dagger analysis so it can be plugged in the future if needed.

I'm still working on having less assumptions as possible that are not strictly dagger related. 👍

[autonomousapps]

Any word on this?

[tbroyer]

The SPI is here (since Dagger 2.14, made _official_ in 2.15, changed in 2.16): https://google.github.io/dagger/api/latest/dagger/spi/BindingGraphPlugin.html, and there's an implementation outputting GraphViz dot files in dagger.example (so not published in an artifact, not easily _consumable_ from other projects): https://github.com/google/dagger/blob/51d049ff958f97bceba324882c478cb1a10f6e15/java/dagger/example/spi/BindingGraphVisualizer.java

Searching for BindingGraphPlugin on GitHub, it looks like others have forked this code, or started their own, but apparently nothing published as a ready-to-use plugin:

• https://github.com/Leland-Takamine/digraph
• https://github.com/donglua/dagger-spi-graph-plugin
• https://github.com/hzsweers/CatchUp/blob/c8cff6701414c6cb49339403d808b463ef77b764/libraries/tooling/spi-visualizer/src/main/java/io/sweers/catchup/spivisualizer/BindingGraphVisualizer.java
• https://github.com/STAR-ZERO/dagger-spi-sample

[autonomousapps]

Thank you!

@dvdciri any chance you could update your project to use this? Or have you already? I checked it out yesterday and it still didn't have support for @Binds, among others. For my purposes, I would really need that, as well as @Inject constructors.

[autonomousapps]

@tbroyer I note that the BindingGraphPlugin interface makes use of default methods. I don't think this would be generally compatible with Android projects, correct? I think I would have to set my minSdk to 26 to have access to that language feature. That's achievable by various methods, but not ideal.

Oh, nm. This code would live in a gradle plugin (for example) as an annotation processor, not in the app codebase.

[JakeWharton]

It runs on the host during compilation, not as part of the app.

On Mon, Jul 2, 2018 at 2:25 PM Tony Robalik [e-mail]
wrote:

@tbroyer https://github.com/tbroyer I note that the BindingGraphPlugin
interface makes use of default methods. I don't think this would be
generally compatible with Android projects, correct? I think I would have
to set my minSdk to 26 to have access to that language feature. That's
achievable by various methods, but not ideal.

—
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/288#issuecomment-401892441, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEEEc5X6FpmQyC8vGlpUA8f-_3_Eir4ks5uCmWSgaJpZM4G9hAj
.

[BOMBeR369]

Any updates on this? I could not get dagger-spi to work on 2.25.2 with example of BindingGraphPlugin from repo, BindingGraph is missing few classes that used in an example, nor could not find any alterative

[trevjonez]

The spi can and has changed over time so the example likely needs to be updated. I was playing with this last week to start generating a gexf file and the SPI works fine. I ran into issues wit the gexf format and its lack of stable versioning.

The more I played with it the more I wondered what the best way to represent the data was, something that can be interacted with might be best so that a one size fits all doesn't need to be imposed.

so far I have found a few tools with nice feature sets that might be options. one is gephi https://github.com/gephi/gephi although seems less approachable.

this article has some nice visuals and diving into them directly shows they can be interactive.
https://queue.acm.org/detail.cfm?id=1805128
all done with https://flare.prefuse.org/ although it seems the projects have gone very stale and use dead tech like flex. https://github.com/prefuse

[tir38]

@trevjonez do you have a link to the work you've done so far?

[trevjonez]

I haven't published anything yet, ran into issues with the gexf4j producing v1.2 and gephi only wanting v1.3 and dropping all my graph edges when opening the file. Have not had time to cycle back on it yet.

issue here sums it up a bit: https://github.com/gephi/gephi/issues/2019

hopefully i'll be able to get back to it in the next few weeks

[arunkumar9t2]

I was able to use Dagger SPI + GraphViz to build https://github.com/arunkumar9t2/scabbard. It also has an IDE plugin to link @Component to generated graph.

Example:

To solve the too many bindings problem, I group the bindings by component path to keep the graph readable, however this has few side effects which I plan to address. (Fixed in 0.3.0).

I also believe with the current SPI, it is possible to build component hierarchy like @pyricau suggested. I plan to try this some time soon. Any feedback greatly appreciated, thanks.

Since 0.4.0, Scabbard supports component hierarchy as originally mentioned in the issue.