Accept tabular input data?

[mbostock]

Rather than taking a tree as input (and a children accessor), it might be simpler if we took a table of nodes as input with id and parent accessors. For example:

id	parent	value
add	methods	593
AgglomerativeCluster	cluster	3938
AggregateExpression	query	1616
analytics	flare
AnchorControl	controls	2138
and	methods	330
And	query	1027
animate	flare
Arithmetic	query	3891
ArrayInterpolator	interpolate	1983
Arrays	util	8258
ArrowType	render	698
AspectRatioBanker	optimization	7074

[mbostock]

Here’s flare.csv. The nice thing about this approach is that it’s trivial to use with a tabular datastore (such as a SQL database), and the serialized form is typically smaller than JSON: 5,532 bytes for CSV, 8,638 bytes for minimal JSON, and 11,634 for readable JSON.

[mbostock]

There’s some empirical evidence that suggests it would be helpful to support this form of input data.

It might be possible to support both forms. Perhaps if you set a parent accessor, it expects tabular input, and if you set a children accessor, it expects hierarchical input?

This issue also feels related to d3/d3#1145 d3/d3#1929 in that it may be easier to create wrapper objects for data—as opposed to setting properties on the input data—if we accept tabular input data.

Also tabular input feels nice because the layout’s output is always tabular, so as to work well with D3’s selections.

Also note that the force layout also takes tabular input, in the form of two tables: nodes and links.

[mbostock]

Related thought:

The force layout takes links as input with source and target properties that default to numeric indexes into the nodes array. It would be nice for those properties to be customized via accessor along with a key accessor to define a unique name for each node. (Possibly, the properties names should be named linkSource, linkTarget and nodeKey if we want to be explicit.) The source and target accessors could return either a key (a string if a key accessor is specified, or a numeric index if not) or a reference to the node. Then you wouldn’t have to manually wire up the graph, as in bl.ocks.org/533daf20348023dfdd76.

Similarly, hierarchy layouts could default so that the parent property is a numeric index into the nodes array. If you specify a key accessor, then the parent property could instead be a string whose value is the corresponding node’s key. You could also specify a parent accessor, which can return either a key or a reference to the parent node.

[mbostock]

Fixed in #14.