[feat] parse method on stratify constructor about d3-hierarchy

[mbostock]

Stratify doesn’t do any parsing; it just assembles the tree using unique string identifiers for each node and its parent. So I am not sure I understand the proposed feature.

There is no requirement that these identifiers be named id and parentId; that is just the default implementation. And the node.data property represents the input to the stratify operator (each node wraps the corresponding input object), so that is more of a design consequence of the nodes than the stratify operator.

[lukaswelinder]

@mbostock Thanks for the quick follow up.

While I'm aware they don't have to be named that, I've hit a few use cases where I don't want the id's to be located on the data object and would prefer the separation of concerns.

My thought was to allow for the user to define what the the data property contained and keep the node related properties on the node itself without having to iterate over the tree to manipulate it afterwards. Sort of similar to the d3-dsv .csvParse() method.

I've made a pull request that partially solves this. More detail in that PR. It's a minimal change, but if you feel that it's outside the scope of stratify then feel free to close it.

[mbostock]

I think I see what you’re trying to do now. Superficially, I’d probably have named your proposed method stratify.data to make it clearer that it’s the accessor that defines the node.data property in the returned hierarchy (and I’d also have passed it the standard arguments including i and data).

But more importantly I don’t think this is the right approach, or at least, I think there’s already a reasonable way to do this, and one that doesn’t require adding a feature to d3.stratify. And that is to iterate over the hierarchy and reassign the data as desired:

var root = d3.stratify()
    .id(function(d) { return d.id; })
    .parentId(function(d) { return d.parentId; })
  (data)
    .eachBefore(function(d) { d.data = {foo: d.data.foo}; });

https://tonicdev.com/571eb333aded861100033e76/57b08e304e962a120052f44f

Introducing stratify.props (or stratify.data) adds complexity for something that can already be done easily, particularly in that there’s now a third object to understand (that becomes node.data), rather than just the input data and the output node that wraps it.

[lukaswelinder]

Missing i and dada was an oversight, thanks for catching that. As for the design, I agree, stratify.props isn't a good name; I decided against calling it 'data' to avoid confusion with the pattern of d3-select. An optional callback similar to d3-dsv parsing methods would probably be preferable.

Introducing stratify.props (or stratify.data) adds complexity for something that can already be done easily, particularly in that there’s now a third object to understand (that becomes node.data), rather than just the input data and the output node that wraps it.

That's a good point. My reasoning for suggesting it was to have a way to do that without the need to iterate over the nodes after stratifying and/or perform operations on the data before stratifying. Operating on the data could be done within stratify.id, but that feels hacky.

Just food for thought I suppose; thanks for taking the time to check out the PR and follow up.