toIncrementalJson results in "Too much Recursion" for certain types of objects

[northwoodssoftware]

toIncrementalJson results in "Too much Recursion" for certain types of objects

[WalterNorthwoods]

So you actually have cyclical references in your data? I do not believe that either Model.toJson or Model.toIncrementalJson** check for that.

For now, I do not have a good work-around for you. Are you depending on maintaining those cyclical or shared references when loading the model back in?

[simonsarris]

If you do really think there is a bug, some data that we can experiment with would be very helpful.

[Glidias]

Hmm.. saw the below Model documentation and i guess it's a limitation that i have to get around with when it comes to integrating GOJs graph's Transaction ChangeEvents with de.polygonal.ds.Graph data structures class. (I'm storing a dynamically Graph-created de.polygonal.ds.GraphNode as a property called "node" within each GOJS Model node's data when a GOJS node is created, and each GraphNode consist of a dynamic val object where all my app-specific data is stored including positioning info). Whatever transactions made on GoJS, is mirrored onto the related de.polygonal.ds.GraphNode/Graph instances accordingly (and i also then run whatever de.polygonal.ds.Graph traversal functions to perform any pathfinding/visibility calculated preview updates, etc. in real time). The thing is, GraphNode class has a next/prev property because it's part of a linked list...which thus results in the "Too much Recursion" problem when more than 1 GraphNode is added to the Graph because Model.toJSON will scan this custom "node" property and run through the "next/prev" pointers in the node's linked list. Also, each GraphNode class instance has a reference pointer back to the Graph that it belongs to, and the Graph also consist of references back to it's GraphNodes.

In Model documentation...

Note that JSON and other textual data formats cannot faithfully store all JavaScript functions. toJson and Model.fromJson do not try to save and load functional property values. You should arrange that all such functions, including event handlers, are established by your app. toJson and Model.fromJson also cannot handle circular references; any sharing of references will be lost too. They also skip properties that are not enumerable, those whose names start with an underscore, and those whose values are undefined.

What I could do though, is perhaps, underscore prefix "_" the node property? Would that skip it? BUt anyway, I think i'm just going to avoid toIncrementalJson for now. But I think I should consider using an integer reference key ID or/and proxy helper setter/getter methods later on or something for the "node" reference, so the actual innards of the class instance doesn't get exposed to JSON.

eg. For the app-specific value object, I have sharing of certain "library" data objects between nodes.

 GoJS Model GraphNode....contains 
 -> de.polygonal.ds.GraphNode....which contains
       -> LocationPacket (unique per node) ...which contains ->
               LocationDefinition (shared content between nodes), 
               LocationDefinitionOverwrites (shared or unique content  among nodes),   
               LocationState (unique per node).

Basically, I need a binding system that allows changing one LocationDefinition's details to affect the visuals of all related Nodes that are using that same location definition library reference. But the data-binding paradigm is purely 1 to 1 (ie. it only visually updates the current instance being updated)...without the possibly of sharing library/theme references between nodes and having the other related nodes update as well. I guess i have to run through the model manually to visually update those nodes with any matching/related definitions via e.model.updateTargetBindings(o, "text");.

My "text" property actually drills into the LocationPacket to see if there is an (optional) label in LocationDefinitionOverwrites or LocationDefinition itself (which can be shared between nodes).... In the end, I resorted to a getter/setter proxy using Object.defineProperty(o, "text", someProxyToHandleGetterSetterOps), because the GOJS two way databinding with conversion functions was a bit too hard to work with this situation which was more complex. I had to manually update the related nodes' bindings in the model that were sharing the same LocationDefinition when I detected a ChangedEvent for "text" property. With a getter/setter proxy, I could also handle various backend database/data-structure resolutions/linkage changes when the "text" property changes accordingly.

[WalterNorthwoods]

I was going to suggest making the "back-pointer" properties be non-enumerable, or prefixing them with "_", but I see now that you have updated your comment to anticipate that possibility.

Yes, using getter/setter properties is another way to solve the problem. It looks like you have a good grasp on the situation. If you have any other questions, contact us through our forum, https://forum.nwoods.com/c/gojs, or by email.