search

jbenet / depviz

dependency visualizer for the web
https://jbenet.github.io/depviz
MIT License
49 stars 10 forks source link

Some issues don't show? #17

Open jbenet opened 7 years ago

jbenet commented 7 years ago

Right now https://wking.github.io/depviz/#/http/github.com/jbenet/depviz/1 is not showing several issues, now that some are closed. I've seen some issues show when closed, so not sure what's up.

This could be an option in a future version. (we could have check boxes on the screen, etc. i'll take a stab at designing that later)

depends on #34

jbenet commented 7 years ago

Correction-- it's not the closed ones that don't show, it's some open ones. see https://github.com/jbenet/depviz/issues/1 -- it should depend on: 2, 3, 4, 5, 6

I see it as:

2016-11-28 at 10 50 am

jbenet commented 7 years ago

Sorry-- i'm being dumb. 2, 3, 4, 5, 6 are all there. others are missing, may be the hop count? (eg 2 depends on 8, 9, 10, 11)

jbenet commented 7 years ago

2016-11-28 at 10 54 am

wking commented 7 years ago

Currently we only fetch nodes that are dependencies of unfinished nodes (something like #13). If we lift that restriction (with a checkbox or some such) we'd need another way to limit expensive graph walking. Some other comments on that in #2.

jbenet commented 7 years ago
wking commented 7 years ago

On Mon, Nov 28, 2016 at 11:09:11AM -0800, Juan Benet wrote:

  • I think maybe the default should be hop depth? (say 3 hops?)

Hop-depth doesn't play so nicely with a draggable graph (it makes more sense if you're traversing the graph by clicking). Click-based traversing is fine, but currently the host icon links to the host and the card title links to the external issue/PR/…. We could make it the card background, but that's starting to feel a bit crowded, and triggering a re-render is expensive…

jbenet commented 7 years ago
jbenet commented 7 years ago
wking commented 7 years ago

On Mon, Nov 28, 2016 at 11:46:25AM -0800, Juan Benet wrote:

  • Also, not sure i captured it well on designs, but original intent was to show some hop-depth down to the dependents of the centered issue too (github does add issue backlinks so that data is traversable, though not 100% it's returned in API)

I don't see it in the API 1, and even if it was there GitHub is unlikely to notice host-spanning dependents (e.g. a GitLab issue which depends on a GitHub issue). Unless we explicitly annotate these (like we do with dependencies), I expect we should not worry about them. That's not very DRY, but it does handle cross-host links.

Stepping back, I expect folks will mostly be interested in “how can I push ${OWNER}/${PROJECT} forward?”. In that case, you don't need dependents outside of that owner/project. So between the difficulty in discovery and the low utility, I'm fine punting dependent walking for now. Maybe we should spin this out into a separate issue and label it with a low priority?

jbenet commented 7 years ago

I explicitly want to understand:

jbenet commented 7 years ago

i hear you on not tracking the external dependents, but think this will vary across hosts. i think we want to err in the side of showing the most of what we can show.

wking commented 7 years ago

On Mon, Nov 28, 2016 at 12:32:51PM -0800, Juan Benet wrote:

I explicitly want to understand:

  • What are all the things this is blocking?

Do you really need this? If you're interested in moving github.com/ipfs forward, it doesn't really matter if they're blocking wking/some-crazy-thing/3. You're interested in figuring out if they're blocking something else in github.com/ipfs. The currently-supported user route (#7) should cover you there, although I expect performance issues if you try to view it now ;). We can address those performance issues with caching/filtering. And once we do that, I'm not sure we need additional dependent discovery.

On Mon, Nov 28, 2016 at 12:34:14PM -0800, Juan Benet wrote:

i hear you on not tracking the external dependents, but think this will vary across hosts. i think we want to err in the side of showing the most of what we can show.

I'm somewhat on board with this (I don't have a problem with showing known dependents). But I'm not excited enough about it to write something to scrape backreferences from the GitHub API, fetch the references, and scan them for dependency declarations ;).

jbenet commented 7 years ago

Sounds good on the above. Maybe we can make that an open issue, and link to the above. meaning:

jbenet commented 7 years ago

Moved the dependents subtopic to https://github.com/jbenet/depviz/issues/25. Rest of this issue is about either traversing a number of hops, possibly click-to-re-center, possibly using :hover to show more links.