-
Notifications
You must be signed in to change notification settings - Fork 39
d3.nest retains node properties after rollup #23
Comments
reference of my stratify comment: d3/d3-hierarchy#33 |
Furthur investigation indicates that that adding .sum() to my heirarchy also strips node properties. Why not a properties node? Consider how labels are created in the example linked above.
So in order to use something within a leaf, you'd either need to make sure its a key along the way, or do lookup from the OG data. Property portability might be more flexible. |
Curious to know if this suggestion is reasonable. |
Apologies for the delayed reply. This doesn’t seem to be an issue with d3.nest. nest.rollup doesn’t strip properties; if you specify a rollup function, you can do whatever you like with the passed-in array of values, and the returned value is what becomes the resulting entry.value. Perhaps you meant to suggest a change to d3.hierarchy instead? That also doesn’t strip properties, but it does (intentionally) wrap the input data. You can access the original input as node.data. |
Its difficult to understand why rollup should strip leaf node properties, when there are all kinds of reasons those properties might be desired for viz/labelling. etc once the nest is fed to d3.hierarchy. I understand that I can have rollup deliver back an object rather than a single value but 1) that is laborous and idiosyncratic to the data set and 2) d3.hierarchy then finds 0/undefined in the "value" property for non leaf nodes.
Maybe stratify handles this better, but in my environment its not feasible to ask my non-viz counterparts to keep a bunch of dead/non-functional rows in their data so stratify can find them.
Can there be a way to for rollup to retain leaf properties in the nest?
The text was updated successfully, but these errors were encountered: