Top level `Graph` API

[kMutagene]

I think consistency over the data viz libs in the stack can have huge benefits. Therefore, I suggest to either re-write this lib to follow the same patterns, or gradually introduce a top-level API.

For example, in Plotly.NET we have something like this:

Chart.Point(x=[...], y = [...])

Internally, there are multiple things happening, as in plotly.js there is no trace named "point". Chart.Point is a simple top-level API that removes the need for deep plotly.js knowledge.

in Cyjs.NET (or Cytoscape,NET, see #11 ), we could have something like this:

Graph.Tree(...) // creates a graph that uses taxi edges per default
Graph.Circle(...) // creates a graph using circular layout per default

not sure about the types of graphs that make the most sense besides Graph.Tree though, so i'd love some input

[kMutagene]

@HLWeil @LibraChris any suggestions on the graph types you'd like to see in such an API?

[LibraChris]

That is a neat idea. A few graph types I think would be interesting to see are:

• [ ] Tree graph
• [ ] Cycle graph
• [ ] Planar graph
• [ ] Bipartite graph

This should cover all common bases in my opinion.

[muehlhaus]

I am not sure. While a homogenic use would be nice, it would quite differ from the classical use of a graph lib... Normal you build a graph and try different layouts... Let's discuss this a bit deeper...

[kMutagene]

Normal you build a graph and try different layouts

While i get this, i do not see it as an argument against the need for a top-level API. The same can be applied to all dataviz libs. I often so not know which Chart.XYZ function will be best for visualizing the data at hand, and i play around with different kinds of charts until i'm satisfied.

Also, there is nothing stopping us from also adding Graph.Empty() to this API.

[kMutagene]

Furthermore, if I would want to build a tree with this library at the moment, there would be quite some ceremony involved, although i know exeactly what kind of layout and edges i want to have in advance.

[kMutagene]

Here are some additional points after some F2F discussion with @muehlhaus and @LibraChris:

• We should not name the top-level API Graph because - in contrast to Chart - it also is the name of a data structure. There is a need of this lib to play nice with a library such as FSharp.FGL that creates and manipulates a Graph data structure, and polluting that namespace with a visualization API is not ideal. This is also the reason why i'll start to talk about a graphvis (graph visualization) from now on to signify i am talking about a visualization created with this library.
• Top-level convenience functions for graphvis such as Tree only make sense when there is more to it other than setting the layout of a graph. Example:
  • Tree needs to set a special edge style (taxi edges) and a layout. It makes sense to add a top-level function to create this graphvis.
  • Circular only refers to setting a circular layout. There is no need for a top-level function to create this graphvis
• The lib will be renamed according to #11
• A core rework coupling the graphvis with needed contextual objects (such as DsiplayOptions to control HTML rendering options) will be done (see this comment https://github.com/fslaborg/Cyjs.NET/pull/13#issuecomment-1519028558)