Automatically box non-hierarchy instances?

[mbostock]

What if this:

var root = treemap(data);

Were equivalent to this:

var root = treemap(d3.hierarchy(data).sum(function(d) { return d.value; }));

You might even sort by default, like this?

var root = treemap(d3.hierarchy(data)
    .sum(function(d) { return d.value; })
    .sort(function(a, b) { return b.value - a.value; }));

And perhaps this:

var root = treemap(data, function(d) { return d.size; });

Could be equivalent to this (sorting TBD):

var root = treemap(d3.hierarchy(data).sum(function(d) { return d.size; }));

Which is a bit like how the d3-array methods take value accessors. It would add a bit of code to each hierarchy layout, but it feels like it might be convenient for the common case… albeit less self-describing.

[syntagmatic]

This seems too magical to be worth it, at least from the perspective of transitioning from version 3. There will be considerable confusion about hierarchy formats because of issues like https://github.com/d3/d3-collection/issues/3

The d3.hierarchy API is useful to encounter and read about, so explicitly declaring it is good for now.

The automatic boxing probably can't work both with code that uses the existing d3.nest (key/values) and the flare.json (name/children) structures... or can it?

[mbostock]

I don’t think you’d want automatic boxing to allow the children to be defined using the values property by default. That would imply d3.hierarchy would allow either, as well, and that seems unnecessary and difficult to implement cleanly.

If we changed d3.nest according to d3/d3-collection#3, old code like this:

var entries = nest.entries(data);
var root = d3.hierarchy({values: entries}, function(d) { return d.values; });
root.sum(function(d) { return d.values; });
treemap(root);

Could be changed to this:

var entries = nest.entries(data);
var root = treemap({children: entries});

In other words:

• You don’t need to specify a children accessor to d3.hierarchy because the default one is now compatible with d3.nest.
• You don’t need to pass the result of nest.entries to d3.hierarchy because the hierarchy layout (treemap) automatically does that if the input isn’t a d3.hierarchy instance.
• You don’t need to call hierarchy.sum, either, because the hierarchy layout automatically does that if the input isn’t a d3.hierarchy instance.
• You don’t have the confusion of entry.values referring to either the children values or the rolled-up value because nest.rollup replaces the leaf entries with {key, value} objects.

Now, you could just take d3/d3-collection#3 by itself and not allow autoboxing, in which case you’d need to say this:

var entries = nest.entries(data);
var root = d3.hierarchy({children: entries});
root.sum(function(d) { return d.value; });
treemap(root);

That’s still an improvement in my view. If you just changed the behavior of nest.rollup, then it’d be:

var entries = nest.entries(data);
var root = d3.hierarchy({values: entries}, function(d) { return d.values; });
root.sum(function(d) { return d.value; });
treemap(root);

Which I guess is still slightly better because it avoids the entry.value vs. entry.values confusion, but I still think it’d be nice to use entry.children instead of entry.values.

You could also support autoboxing but reject d3/d3-collection#3, in which case the example here would remain unchanged since d3.nest wouldn’t be able to take advantage of autoboxing. But autoboxing would still help if you had hierarchical JSON data and you just wanted the default behavior in regards to sorting.

[mbostock]

Okay, I think I’m against autoboxing in that: it doesn’t introduce the d3.hierarchy API (and violates parsimony); it requires specifying default behavior in all hierarchy layouts; and it’s not useful in the case where you have tabular data and need to use d3.stratify.