Reading through the paper for YATA it mentions that it can be used for graphs. Is there an example of this? From what I could figure people usually have a map of nodes and a map of edges. With that that though, what happens if someone removes a node (and all connecting edges) in their client and another client adds an edge to that node? It seems like the new edge would still be added. This seems like it would be an issue with any piece of data that had multiple parents (as otherwise they could just be put in a map). I could imagine a garbage collector that would check and remove these as the changes came in, but is there a better way? Guessing that a graph like that (or tabular data) could be implemented as types…
There is an example GitHub - micrology/y-vis-network: Example of yjs used to share an editable network graph with vis-network
I ran the example and can confirm that what I said is an issue. If you run 2 clients, and add 2 nodes, disconnect one, then add a link in one client and remove a node in another then reconnect you will end up with an extra edge in the edge data set. The client does not have an issue with this because the vis-network won’t connect an edge where the nodes don’t exist: vis-network/Edge.js at master · visjs/vis-network · GitHub. To fix this there would need to be extra logic when adding an edge to check that the node was not removed and not add it - or add it as a deleted node? I don’t believe that’s too bad though. For more context we’ve got some OT applications that do spreadsheets (which have a similar issue as a cell has a row and column - thus multiple parents) and this is handled in the transformers (because they know to look for a delete of either parent and so can remove the op). We’ve also got a graph application which is being done now. So the three options would be 1) leave it - not too bad as we’d just be marking them deleted anyway. It would be up to application code to make sure it deals with orphaned items, this would only be an issue if the values were large 2) change the bindings to check and fire a remove if the item is orphaned - adds extra logic to the bindings 3) have a process that garbage collects orphaned items - means a whole other process and the app will still have to deal with orphans
Though it might be preferred to leave as is so an undo on removing the node will also bring back that edge…
2 Likes