How to group commits in a transaction for Async functions?

GoJS
1

Hi team, Below is our scenerio where we want to skip transactions / group commits so they can safely be undoed and redoed without any breaking.

From what I found the best way to do this is to wrap all the commits we want to be grouped together for the undoManager in a single transaction.

In our framework we have async functions doing most of the work. For example,
after a drag and drop we have a handler that will be doing multiple functionalities each within its own Async function. Please suggest on how we can achieve undo or redo with async functions where we want to group commits.

Also please correct me if I am wrong about my understanding that a transaction will act as a group of commits what will be added as a single step in undoManager.

2

GoJS was designed and implemented before Promises, and thus long before async/await.

If I understand your situation correctly, you have code like:

new go.Diagram(. . ., {
  . . .,
  "SelectionMoved": async e => {
    await makeDiagramChanges1();
    await makeDiagramChanges2();
   }
})

And those async functions modify the Diagram or its Model, but you want all of those changes to be included in the “SelectionMoved” transaction performed by the DraggingTool. Are they conducting their own transactions, or are they just making changes that will be included in the next top-level transaction?

I suppose we should have a method on UndoManager that combines two consecutive Transactions into one Transaction. Would that satisfy your requirements?

3

Yes. That is similar to what i was asking.

Some of them do diagram.commits and some of them as direct changes that might cause a entry in undoManager like part.visible = false;
These are causing extra undo steps which we want to mitigate.

Please suggest.

4

I don’t think you should be executing something like part.visible = falseoutside of a transaction, so I’ll assume that such code is being performed by one of your calls to Diagram.commit.

Still trying to understand your situation, I believe that means that all of those asynchronous diagram changes that you want to include in the original “SelectionMoved” DiagramEvent and Transaction are happening within top-level transactions that cause additional Transactions to be added to the UndoManager.history. If that is the case, then what I suggested previously might help.

The code to combine Transactions is pretty straight-forward, but it depends on the ability to modify internal state of both the UndoManager and a Transaction. So I’m unable at this time to provide code to do what you want. But I’ll put the functionality into the next release of 3.1.*.