UndoEngine

graph.undoEngineEnabled = true

The UndoEngine is in charge of recording, managing and executing single units of work that can be undone and redone, represented by the interface IUndoUnit.

const engine = graph.undoEngine

These units are managed in a queue-like structure and can be added manually to the queue by calling the addUnit method.

engine.addUnit(myUnit)

Executing the units is done by client code or commands by calling undo or redo. The engine automatically manages the queue so that calling these two methods will consistently move the units in the queue.

The beginCompoundEdit method allows to record units by bracketing several changes in an ICompoundEdit. Implementations of the ICompoundEdit interface record all subsequent changes until it is committed and therefore all recorded units are added to the engine. For more information and examples see ICompoundEdit.

const edit = engine.beginCompoundEdit(undoName, redoName)

// add custom undo units or change the graph structure programmatically here

if (!success) {
  // if we don't want the changes to be done after all, then we need to cancel the edit
  edit.cancel()
}

Depending on the properties mergeUnits and autoMergeTime, the engine tries to collapse added IUndoUnits if possible. This enhances the performance and reduces the required memory for undo changes. For example, when a node is moved interactively, instead of saving every position that the node had when being dragged the engine will only hold one IUndoUnit at the end to undo the entire movement.

Customizing Undo/Redo

• In general, to be able to undo or redo certain work client code can implement IUndoUnit or subclass UndoUnitBase. The client application needs to encapsulate changes in this implementation and provide the logic to completely undo and redo these changes. Instances of your custom IUndoUnit implementations need to be added to the UndoEngine manually via addUnit.
• In certain cases it is difficult or not efficient to track and save the changes between certain states, and better to save the states themselves and to restore these. For example when there are potentially many intermediate steps between two states of interest and it would be complicated to produce IUndoUnits for each intermediate step and merge them in the end. In such cases client code should implement IMementoSupport instead. See the documentation of IMementoSupport for examples and guidelines on how to implement this memento design pattern concept.
• It is generally not necessary to subclass UndoEngine unless you want to customize the internal handling of the units, which is both complicated and prone to errors. In most use cases it is sufficient to provide custom IUndoUnits or IMementoSupport.