Use an adjacency list data structure to represent graph

[ianjsikes]

See #38 for an explanation of my motivation for this change. tl;dr: It makes graph traversal easier, which will help with the "Focus mode" feature I am building up to.

There are a couple of other tweaks I made for convenience, but I'm happy to roll those back if needed.

• I combined the "click" and "refresh" messages into one. The extension passes a single State object to the webview that contains the current node ID and the graph. I've found that it is a lot easier to track and debug the graph by having all the state together like this. This might be my personal bias to doing things in a React-y way (thinking of the webview like a React component, full rerender on prop changes).
• I updated d3 to the latest version (v5.16.0). The only real reason for this was because it was difficult to find code examples and docs for the older version. This should probably be a separate PR though...

[tchayen]

@ingalless

As we are getting towards more serious data structures here, I would really love to know your opinion about how it fits (or repeats, or breaks) what is happening currently at Foam (as I am completely lost in the current development progress).

I remember that there was work on proper JS abstractions for storing the graph on the side of foam-core (IIRC) and I remember having some discussion with someone about exchanging data between extensions. What is the status of that? I am thinking about it in terms of whether it will look similar to what we are heading here, where it would make sense to share work instead of discovering, calculating graph two times etc.

Basically I would love to hear anything you would like to add on this topic 😄 .

[ingalless]

@tchayen I think I'm just as clued up as you are on this subject

There hasn't been a huge deal of development from what I understand over the past couple weeks. Real development starts in September, so we may find out more then

But from what I've read whilst lurking is that they do want to provide the serialised graph data to help minimise the number of times the markdown needs to be parsed.

Unfortunately, I'm quite fuzzy on how all this graph stuff works

He's a busy bee, so we may not get a reply, but: cc @jevakallio in case he can clue us into the plan

I'll try have a dig around tomorrow in discord if I remember to! I'll update if I find anything else. But your understanding is what mine is currently: they may provide the data serialised so that files are only parsed once

[ianjsikes]

That's a great point @tchayen . Foam is using https://github.com/dagrejs/graphlib to represent its graph. I haven't used it myself but it looks like it handles all the graph operations we'd need plus a bunch of neat pre-implemented algos. I recently talked with @jevakallio a bit about sharing graph data between Foam and Markdown Links. It seems like there are a couple of options when it comes to working with Foam:

• Include foam-core as a dependency, and use its same graph generation code for Markdown Links. This is something we could do today. It isn't ideal because it is still doing the same work as Foam twice, but it would be very consistent with how the Foam extension works.
• Use some sort of inter-extension communication (like LSP or reading from a file Foam writes). There's more work to be done on Foam's side before something like this is ready to be implemented.

The obvious downside to both of those, however, is it puts a hard dependency between Foam and Markdown Links. But, something we could do is use graphlib for the graph (instead of my shoddy DIY graph), and then if we want to interop with Foam, it'll be easier in the future since it is the same data structure.

[ianjsikes]

Anyway I'd be more than happy to try to redo this using graphlib

[tchayen]

I don't mind having Foam as a code dependency. But on the other hand I do care about staying true to the extension's name and keeping support for other ways of writing markdown files, not necessarily the Foam's way.

The LSP sounds like what we really need here. How I see it could go:

• we can stick to pretty much any representation we want (graphlib sounds cool if you want to)
• we can prepare a way for markdown-links to have graph data injected instead of discovering the files on its own (but my vision is blurry and I don't have much hope we will be able to figure it out until LSP is done on the Foam's side so we will have some idea how it can look)
• optionally some graph data conversion will be needed too