Accept tabular input data? about d3-hierarchy

[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.