I need to track the changes to the UI graph and apply them to some data model. However, the input and output IDs of the connections don't tell me much, I really need to know the indices within the connections (as in, was it connected to the 2nd input or the 1st output, etc.). I think the only way I can look those up (apart from doing separate bookkeeping) is to query the nodes in question and then look up the id in their list of inputs and outputs, respectively.
But then I run into a problem with deleted nodes, because by the time you're handling the NodeResponse, the node and their input and outputparams are already removed from the graph.
I did some digging through the source code, and it seems the order of events is as follows:
DeleteNodeUi
<potentially some other events>
any number of DisconnectEvents (generated by DeleteNodeUi)
DeleteFullNode (generated by DeleteNodeUi)
Now, the DeleteFullNode contains the original Node, but I really like to know that during the DisconnectEvents caused by the removal of that node.
Of course there are some ways around this. I already mentioned separate bookkeeping, but one could also query whether the node exists during response handling, find out that it doesn't, and then queue up those events so you can process them when the the DeleteFullNode for the respective node comes around.
I don't see a good solution from the API side though. Perhaps some shadow storage that keeps the data around until the next update? In any way, it might be a good idea to mention in the comments that the IDs as reported by the events might be stale.
I need to track the changes to the UI graph and apply them to some data model. However, the input and output IDs of the connections don't tell me much, I really need to know the indices within the connections (as in, was it connected to the 2nd input or the 1st output, etc.). I think the only way I can look those up (apart from doing separate bookkeeping) is to query the nodes in question and then look up the id in their list of inputs and outputs, respectively.
But then I run into a problem with deleted nodes, because by the time you're handling the
NodeResponse, the node and their input and outputparams are already removed from the graph.I did some digging through the source code, and it seems the order of events is as follows:
DeleteNodeUi<potentially some other events> any number ofDisconnectEvents (generated byDeleteNodeUi)DeleteFullNode(generated byDeleteNodeUi)Now, the
DeleteFullNodecontains the originalNode, but I really like to know that during theDisconnectEvents caused by the removal of that node.Of course there are some ways around this. I already mentioned separate bookkeeping, but one could also query whether the node exists during response handling, find out that it doesn't, and then queue up those events so you can process them when the the
DeleteFullNodefor the respective node comes around.I don't see a good solution from the API side though. Perhaps some shadow storage that keeps the data around until the next update? In any way, it might be a good idea to mention in the comments that the IDs as reported by the events might be stale.