Optional node.fixedValue to override size of node

[sillitoe]

We have a use case where it is useful to allow the size of each node to be larger than the sum of the link.value (overriding the default case).

e.g.

I can't figure out a clean way of implementing this in the current API, so I've added a local workaround that allows an optional node.value to be added to the existing Math.max calculation.

Is this (or a better implementation) something that might be useful to others?

Thanks,

Ian

[elliotchi]

+1 on this. Can we get this merged?

[dandelany]

+1, this would be really valuable for my use-case as well! Would be great if this were supported.

[craigmcginley]

+1

[bvoisin]

+1, can we help to get it merged ?

[geekplux]

+1, this would be really useful

[sillitoe]

@mbostock ?

[mbostock]

The issue I see with this design is that you can’t run the Sankey layout again on the same input: the node.value set by the previous run of the Sankey layout becomes the new minimum value of the node. So, this is not strictly backwards-compatible.

We tackled a similar issue in d3/d3-hierarchy#9 by wrapping the input data, so that the layout isn’t overwriting the same value it reads from. I think we’ll probably want to do that with the Sankey input, too—to treat the input data as immutable, and to wrap it with whatever the layout generates.

A super-simple way of avoiding this problem would be to read from node.minValue instead.

[sillitoe]

Thanks, yes that seems a much better design - added in c03678f.

[mbostock]

Thanks. Would it be better specify a node.fixedValue, rather than a node.minValue? Then you would say:

node.value = node.fixedValue === undefined
    ? Math.max(sum(node.sourceLinks, value), sum(node.targetLinks, value))
    : node.fixedValue;

[sillitoe]

I figured this might cause a rendering problem if the nodes were smaller than the incoming links?

[mbostock]

Yep, but isn’t that more of a data problem than a rendering problem? It seems better to do that than to ignore the input value.

[sillitoe]

Yes, makes sense. Looks good to me.

[vdubr]

Hi, what is the state of this pull request? This function would be very useful for us. Can I help?

[vdubr]

Thanks