viz.js 2 release

[nwolverson]

Are there any further changes required on top of the existing updates to use viz.js 2.0?

Can assist/test if that's of use

Otherwise is it possible to tag a release?

[csicar]

The reason I did not create a new release yet is, that the API at the current commit of purescript-graphviz is incompatible with the API of the last release.

While working on matching the API up, I went down the rabbit hole of considering https://github.com/dagrejs as the rendering engine (because vizjs recommends it) and than considering implementing a layout engine directly in purescript, instead of writing bindings to the dagrejs library.

Would you like to use some features from vizjs2 or are you missing features in the release of purescript-graphviz?

[nwolverson]

No specific vizjs2 features, it was actually a bit of confusion around reading the README on master and using the latest released version, so ending up with JavaScript errors due to accidentally pulling in the wrong viz.js version.

I think the dagrejs option sounds promising (well, directly in purescript sounds interesting but also scary) - I know @adrianroe has some experience with both and is looking at using this in PS just now

[adrianroe]

For a bit of context I've used vis.js pretty heavily - first in pure JS, then from Elm. We moved away from vis.js as the layout options for the nodes themselves are pretty limited and instead wrapped Dagre to do the layout calculations for nodes we rendered ourselves (at positions Dagre suggested).

We are in the process of migrating from Elm to Purescript and I was playing with this repo to see what had already been done. @nwolverson helped me work out the version mismatch I'd inadvertently introduced...

It's an interesting rabbit hole to go down and I be interested in helping with some Dagre wrappers if you do jump in! (albeit I'm new to PS)

[csicar]

Oh, I see. In that case changing the README on master would be a solution?

Dagre seems to be a reasonable choice for layouting.

Would it be possible to keep compatibility with DotLang when using Dagre?

I'm happy to get any help on implementing the backend using Dagre :)

[adrianroe]

Yes - it would be straightforward to do a mapping from the graph description in https://github.com/csicar/purescript-dotlang.git to Dagre mappings. About the only suggestion I would make is that (albeit for a pretty complex use case - we were rendering collapsable, hierarchical graphs with real-time data, graphs etc overlaid) it helped us a lot to separate the layout (Dagre) from the rendering (HTML / SVG). Most of DotLang seems to be about the graph structure with just a little rendering (labels etc). That's not too bad for simple use cases (you can guess at the rendered size of a label) but we ended up having to render our nodes offscreen and then query the DOM to find out how big they actually were and then pass that information to Dagre so it could suggest a layout which we then made visible...

I also note that https://github.com/amhuppert/purescript-dagre already exists, so the mechanical bindings might already be in place

[csicar]

Another Querstion:
Does Dagre offer an option for rendering to svg?

it helped us a lot to separate the layout (Dagre) from the rendering (HTML / SVG)

I think the solution for that would be to extend the purescript-dotlang package like this:
Definition will be come Definition a so allow any definition to be annotated with a layout-location.

Layouting with Dagre would be accomplished using a function with type :: Definition Unit -> Definition {x: Int, y: Int} or similar.
To display the graph to the user you could use the additional information ({x: Int, y: Int}) in the view function:

view :: Definition {x: Int, y: Int} -> Html _
view (Node {x, y} ...) = div [top y, left x]

Would that be a solution for you?

I wanted to add that functionality a long time ago, but vizjs did not make that easy

[adrianroe]

Dagre itself does not do rendering (which I think is a good choice), but there are lots of libraries on top of Dagre that do (https://dagrejs.github.io/project/dagre-d3/latest/demo/interactive-demo.html, http://js.cytoscape.org etc and those libraries do allow rendering to SVG). This separation is what made Dagre so much more usable for us with the rendering work we did in Elm.

So if you "just" want simple rendering of graphs, the viz.js stuff you already have is probably a good place to be. If you want more control then a wrapper around Dagre would be a good place (and render yourself) or maybe you want a wrapper around one of the libraries that itself wraps Dagre :)

Dagre itself uses the language defined in graphlib (by the same author) to describe the graph, so maybe that would be the thing to target from dotlang. I would probably have a "renderedDotlang" that enriched the dotlang with things like width and height of nodes and then a further description for a laid out graph. I think I had that sort of separation in my Elm code and it seemed to work well.

I'd be interested in @nwolverson views on the subject as well. This is turning into a rather interesting discussion!

[csicar]

In that case I think starting a new library would be the best option.

That way, everyone expecting "perfect" graphviz rendering can use this library and for users, who just want graph-layouting we would create a new library.

[adrianroe]

I agree - new library.

Apologies for the slow reply - I'm travelling almost non-stop starting now for the next 5 weeks :( .Will try to look here / correspond direct on suggestions for the new library, but I'm likely to be slow replying I'm afraid.