search

dollabs / planviz

Planning Network Visualization
Apache License 2.0
14 stars 4 forks source link

Extracting UI.cljs into less tightly coupled graph visualization #2

Open Conaws opened 8 years ago

Conaws commented 8 years ago

Not sure if this is the right place to put this, but I was very inspired by the SVG graph (and tree) layouts demo'd at Clojure/West. Wondering what you feel one would have to do in order to extract the logic of these into something less tightly coupled to the rest of the system.

For instance -- if one were working with a Loom graph, or a datascript db -- what from here would translate well?

To take a high level overview

  1. view-box to layout the whole svg and there must be some fn to determine how much space the view-box takes up or it just takes some portion of the page by default
  2. a way of translating the topology of the graph into x-y coordinates for lines and circles rendered in the viewbox.
  3. my guess is you're embedding foreign objects in the viewbox to make things clickable or interactive

it looks like tool-tip could be extracted easily, and link-arc looks interesting

Looking mostly at ui.cljs, it looks like the data from the plan is getting passed into the node, edge, and label components as factorys?

Also, looks like this is setup to have the graph animate based on the changes to the data -- how do you imagine that would look if extracted out?

tmarble commented 8 years ago

@Conaws thank you for your comments!

Yes it is desirable to factor out the "generic" SVG graph processing from planviz. We have considered using Loom. Project priorities being what they are we might not be able to get this done immediately, but we share the same goals.

The function planviz.actions/vp-listener is designed to track size of the browser window (i.e. viewport) at a deliberately slow rate (as to avoid an avalanche of events).

The "magic" of using SVG is all in setting up the viewBox. The viewBox gives the dimensions of the graph in SVG coordinates while the svg attributes left, top, width, height determine the degree of panning and zooming. So the really nice answers to 2) and 3) above are simply no: there is coordinate translation from SVG coordinates required and the nodes and edges are all first class SVG circles and paths. We get the clickability (and CSS styling) for free because they are just standard web API's :)

I encourage you to run the demo with your favorite browser debugging tools on which will allow to you inspect the DOM and "see" the SVG as rendered.

The design of planviz is informed by the data model from the TPN and HTN design. The data model is implemented with om.next in planviz.components. To keep the components namespace simple and focussed on data the actual rendering subroutines have been placed in planviz.ui. As currently implemented planviz.ui is very specific to the planviz.components data model. In om.next data is used (with the factory functions) to create React components (which have a render method).

The use of sablano to give a very Clojure data feeling to creating the DOM along with the use of hover styles in CSS to create tooltips concepts can be reused directly in a new program (of course). I am particularly proud of link-arc knowing how to draw temporal constraints as arcs between two nodes (that trigonometry may be useful on it's own).

There isn't any facility for exporting the SVG at the moment nor "animating" it based on TPN execution. The changes you see during execution (in the ClojureTV video) are based on node and edge attribute changes which are translated into different CSS styles when rendered in planviz.ui. Finding the right abstraction to extract this approach seems a little challenging, but would be desirable.

--Tom