-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
toIncrementalJson results in "Too much Recursion" for certain types of objects #21
Comments
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? |
If you do really think there is a bug, some data that we can experiment with would be very helpful. |
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...
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.
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 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. |
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. |
Anyway around this? It seems the codebase doesn't use JSON.stringify to handle the JSON creation, because I created a custom "toJSON" method to prevent recursion, but the output for toIncrementalJSON (it uses the full output) differs from the one in JSON.stringify.
http://stackoverflow.com/a/3895474
The text was updated successfully, but these errors were encountered: