model.removeArrayItem affecting more than one node when using copy/paste

GoJS
1

Hello. I’m running into an issue when copying/pasting nodes with bottom ornaments. This issue is triggered when I:

  • Add a node to the graph (node A)
  • Copy the node
  • Paste the node (node B)
  • Update the bottom ornaments for node B (more details below)

In this scenario, the bottom ornaments for both node A and node B are updated, when only node B should be updated. Here’s the process we use to update the bottom ornaments:

const newBottomOrnaments = [];
const nodeId = '<a node id>';
const node = diagram.findNodeForKey(nodeId); // This returns the correct node

// Clear out our bottom ornaments
const bottomOrnaments = node.bottomOrnaments;
for (let i = bottomOrnaments.length - 1; i >= 0; i--) {
  model.removeArrayItem(bottomOrnaments, i);
}

// Add any new bottom ornaments
newBottomOrnaments.forEach((bottomOrnament) => {
  model.addArrayItem(bottomOrnaments, bottomOrnament);
});

It seems the issue is that both nodes share a __gohashid for the bottomOrnaments array. So, we’ll have something like the following after pasting what was copied:

nodes = [
{ id: 'abc123', bottomOrnaments: [{ icon: '', __gohashid: 1234 }]},
{ id: 'xyz456', bottomOrnaments: [{ icon: '', __gohashid: 1234 }]},
]

We’ve tried a few solutions to resolve this:

  • We’ve set copiesArrays: true and copiesArrayObjects: true for our model. This didn’t do anything for us.
  • We setup copyNodeDataFunction where we iterate over the bottom ornaments, stripping out __gohashid.

The latter approach works, but it feels like a hacky solution. I’m wondering if there is a better approach to take to get this to work?

2

First, you shouldn’t be saving the “__gohashid” property, and you certainly shouldn’t be setting it or copying it.

Second, I think you are correct that the problem is that the Array is being shared by the two node data objects, which cause them to be shared by their respective Nodes. I’m surprised that setting both Model.copiesArrays and copiesArrayObjects to true didn’t help. Can you check in the debugger to make sure that the Diagram.model has both of those properties set to true?

3

I inspected both of the properties and they were part of the model/set to true.

Just wanted to clarify that the data presented up above was fetched via model.nodeDataArray. We aren’t necessarily storing the __gohashid anywhere. I just noticed it present in the arguments of copyNodeDataFunction and noticed it was duplicated when logging model.nodeDataArray

4

Sorry, I mistyped the name of that Model property: Model.copiesArrayObjects.

I’m curious how to reproduce the situation that you encountered. The normal data copying behavior of models, either for the top-level Object or for Objects held in Arrays, explicitly avoids copying the value of “__gohashid”.

BTW, in v3 we will no longer use that internal “__gohashid” property on model data objects. So this confusion won’t happen then.

5

Does this happen before copyNodeDataFunction, or after? I ask because __gohashid was present in the first argument w/n that function

6

The standard/built-in data copying methods will avoid copying any value of “__gohashid”, although then the use of the data may get a new value for “__gohashid”.