Multiple edges between nodes

[aj47]

Describe the bug
I'm trying to have multiple edges between the same two nodes but i get a same key waring and no extra edges rendered. how can i get around this?

Warning:

Warning: Encountered two children with the same key, `Trump,order`. Keys should be unique so that components maintain their identity across updates. Non-unique keys may cause children to be duplicated and/or omitted — the behavior is unsupported and could change in a future version.

[grant37]

I was also looking at this. Seems the key for a link is always created from the source and target node ids in graph.renderer.jsx. You can see it in the _renderLinks function around line 37:

const sourceId = source.id !== undefined && source.id !== null ? source.id : source;
const targetId = target.id !== undefined && target.id !== null ? target.id : target;
const key = \`${sourceId}${CONST.COORDS_SEPARATOR}${targetId}\`;

So I think avoiding the react issues mentioned in the key warning would require a change to that line setting the key. Maybe including the link.labelProperty in the key or using a link.id property if one was added to the link config. Anything I guess that would allow creating a unique link id for any link that gets passed into the Graph via data.links array prop.

But I think because the actual svg links seem to be drawn from the source and target node origins two unique links between the same nodes would still render on top of one another. Not sure that’s true or not. And being unfamiliar with d3 not sure if it would be easy to change or not. Maybe curved links would show up if their paths are somewhat random?

[aj47]

Thanks for the insights grant, yeah it seems possible with d3 js as per this jsfiddle i found on stack overflow http://jsfiddle.net/7HZcR/3/

[danielcaldas]

Yes, currently we can only have one link between two nodes. We can work to expand this functionality, I see two alternatives:

1. We generate an internal identifier that avoids collisions appending some kind of count to the source - target, react-d3-graph would have to keep track of links to detect duplicates and generate unique key values.
2. The user provides within each link something unique that could be used to generate the key alongside with the source and target properties.

To be honest option 1. does not look bad at all... What do you guys think @aj47 @grant37 @LonelyPrincess @wendymungovan

[wendymungovan]

I think option 2 will make it easier when the user makes updates to the existing graph data. This makes them responsible for keeping track of which link is which and not the library.

[danielcaldas]

Good point @wendymungovan, it's also easier for clients to the scale the complexity accordingly if they are in control, given this option 2 is also very valid, but I would not yet discard option 1. Let's see what do the others think about it?

[grant37]

Hmm I guess each has its advantages. I think @wendymungovan is right that the second option would be a bit easier to implement. And the user might off-hand have a simple way to generate unique ids based on their data that doesn't use the index of the link in the links array. Because my initial thought was that the indices would make option 1 pretty simple but then I guess you want to avoid using indices for uniqueness in keys when the order of elements isn't static. @danielcaldas did you have an idea in mind for managing the keys internally in the first option? Anyway, I'd be open to whichever you all feel will work.

[LonelyPrincess]

I agree with @wendymungovan in that we should give users a way to handle those links themselves. I think it's better to give the users as much control as possible, so if I'd had to chose, I'd go with option 2 as well.

As for the first option, I can't think of a way to implement it, because keeping track of the changes when the user modifies the data doesn't seem possible unless the user himself has provided some kind of id in the first place.

We could do what you say and assign each link an internal identifier by using the linked nodes and a counter, but... How would that allow us to identify which is which when the data changes? If the user changes the color for one of the links between two nodes A and B, how can we know for sure if the change happened into A-B-1 or A-B-2? 🤔

When we create the internal id we're only considering the value of the source and target properties, but multiple nodes can share that. We could append a counter at the end, but that value will depend entirely on the order in which the links appear inside of the data object. If the user removes one of the links between a set nodes or just changes the order of the items in the links array, our internal ids could be no longer be pointing to the right place.

Having said that, it seems the more logical to make the users responsible of managing the identifiers of their links, as they already do with the nodes. What do you think, @danielcaldas ?

[danielcaldas]

From your feedback it seems that option 2 would be our best chance, I also like it and it will help us keep the codebase clean and generic 🙂

Another thing to bear in mind is that I think this should not be an opt-in feature. Once we define in react-d3-graph API that clients must provide unique identifiers within link payload, this will no longer be compatible with the current API that we have within v2 of the library. I will, for this reason, deprioritize this issue and try to get as much as bug fixes and other non-impacting features into v2 of the library also given that this one is quite recent.