d3.hierarchy should allow a children accessor.

[mbostock]

It’d be nice to have an example which uses d3.nest to create a hierarchical visualization. For example:

var root = d3.hierarchy(data, function(d) { return d.values; });

[mbostock]

It’s tempting to make this a configurable function:

var root = d3.hierarchy()
    .children(function(d) { return d.values; })
    (data);

This would allow us to specify a default value function and a default sort comparator. These could be disabled if you didn’t want them:

var root = d3.hierarchy()
    .value(null)
    .sort(null)
    (data);

However, I think it’s probably not a good idea to do this, and instead keep d3.hierarchy as minimal as possible. First, it avoids this awkward construct in the common case:

var root = d3.hierarchy()(data);

And second, we’ll still need node.sum and node.sort if we want to do in-place modifications of an existing hierarchy. Currently, calling node.sum is the only way to implement a stable update of a squarified treemap because it updates node.value without destroying node._squarify (the latter being where the tiling method stores the previously-computed layout). We could of course provide both, but that violates the principle of parsimony, as well as doing some unnecessary work by default (if you don’t want to sum values or sort siblings).

[mbostock]

Also, if we supported hierarchy.value and hierarchy.sort, we’d have to add similar methods to d3.stratify for consistency. That’s another reason to stick with node.sum and node.sort, which works with both.

[akre54]

Thanks! I was just about to ask for this. (c.f. d3/d3#1518)