Custom key, values field names for the nest() about d3-collection

[mbostock]

Thanks for the suggestion and pull request. However, I don’t understand why it is useful to allow these names to be specified by the caller (other than the linked Vega issue, which seems to be a Vega feature request rather than an issue with d3.nest’s API), especially given that the caller could map the return value of nest.entries if different names are desired.

[nyurik]

@mbostock nest() mixes together user's data and the generated data in the output. If input data already contains key or values fields, and I had to analyze the output, it might be more difficult to tell apart original vs generated.

How about a different implementation: a factory(key, values) that gets called by nest to create new elements? By default it will be (key, values) => ({ key, values }), but user would be able to supply a different implementation?

[mbostock]

nest.entries returns a nested structure dictated by how many keys you define using nest.key; there is no ambiguity or mixing of input data fields with the {key, values} entries.

[nyurik]

@mbostock understood. Would my alternative idea work though? Because there could be a lot of cases when you want to customize the creation of the new nodes?

[nyurik]

@mbostock here's a PR for a more generic approach - a factory method to customize new node creation. With this approach, users won't need to do complex post-processing iteration of the whole tree if they need to calculate sub-aggregations on the portion of the tree, or if they want to attach additional values to each node. What's more, they might not even want to construct the result tree at all - making nest() into an iteration system instead of an object generation. #27