foambubble / foam

A personal knowledge management and sharing system for VSCode
https://foambubble.github.io/
Other
15.23k stars 650 forks source link

Graph in published workspace #58

Open mathieudutour opened 4 years ago

mathieudutour commented 4 years ago

Opening this issue to discuss what it should look like and what are the technical solutions to show a graph in a published workspace.

In the gatsby-theme-garden (which can be used out of the box with foam), I implemented such a graph

Screenshot 2020-07-05 at 11 44 01

I also added a small feature to keep the graph as a "minimap", pretty much like how Foam does it in vscode

Screenshot 2020-07-05 at 11 44 13

It does require a build step (done in a GitHub action). I'm guessing it could be possible to do the same with a jekyll template tho.

mryap commented 4 years ago

Can I ask how do you go about generating this Referred in title at your stacked page? image

Thanks

mathieudutour commented 4 years ago

Using https://github.com/mathieudutour/gatsby-digital-garden/tree/master/packages/gatsby-transformer-markdown-references

nixsee commented 4 years ago

I love this - its very similar to something I made 4 years ago to use with a wordpress blog that I never really followed through with. I used d3js' force directed graphs, which also allowed for splicing in a variety of other d3js snippets for pan, zoom, search, node colors and sizes, center on selected node/page, show nodes that are x # of links away, filter based on tags & categories, etc... So, it seems to me that leaning on d3js (which appears to be compatible with gatsby vs graphql, react and other stuff) would be a good thing to consider. Or perhaps its all perfectly possible to do with other tools that you're more familiar with.

I'm not really a capable coder (my very kludgey tool took me MONTHS to splice together), so I probably can't really be all that useful for building/integrating any of this into what you've started. But a gatsby-based Foam is ultimately what I'd like to be using this all for, so I'd be delighted to share/brainstorm with you if you're keen to do so! Either way, I'll try to dig up some stuff from my notes and backups to share for inspiration.

mathieudutour commented 4 years ago

I used d3js' force directed graphs

That's what I've been using as well https://github.com/mathieudutour/gatsby-digital-garden/blob/master/packages/gatsby-theme-garden/src/components/graph-visualisation.js! But my implementation is probably terrible, I don't have a lot experience with D3.

There are a few more details about graphs in Foam here: https://github.com/foambubble/call-for-visualization

nixsee commented 4 years ago

No kidding. Thanks for pointing me to your d3 code! Given that you've done what is (to me) the hard work of getting d3 to work with Gatsby, I'll see if I can somehow splice in some of the stuff that I had previously made. I've got nothing but time these days, so it would be wonderful if my many months of blind trial and error could be put to good use finally! I'll share something here/with you if/when I have some success.

Is getting your code up and running really as easy as the 1, 2, 3 in your instructions?

nixsee commented 4 years ago

So I was able to get this set up and test out. Very nice! But it is extremely slow when there are lots of notes (I imported about 500) - the graph inches open and closed over the course of 10+ seconds, and zooming and panning is basically not possible. If I should be commenting on the performance at your digital garden repo instead of here, please let me know. But the same problem happens with the current Markdown Links extension as well.

Obsidian works flawlessly with the same dataset - they use a combination of d3js and Pixi.js so perhaps pixi is doing something that handles the size better. Also, I know that d3 has the capability to use svg and canvas - canvas being far faster for larger datasets, with some other tradeoffs.

So, as far as Foam is concerned, it seems to me that whether its the local or published workspace, size/performance needs to be optimized before anything else (filters, colors, focus, node size, etc...) is discussed.