Introduce Undo/Redo Semantics and Implementation

[ryanvolum]

Currently the user experience in the app involve multiple back-to-back NL -> Code interactions. While the code often accomplishes what the user set out for it to do, it also makes mistakes. Frequently, backing out of these mistakes (e.g. deleting the resources created, resetting the animation changed, moving a mesh back) is difficult to do. Instead, we should introduce semantics for undoing and redoing a change.

There are a couple of ways we can do this:

• Create some kind of checkpoint of a scene (scenes may be serializable?), maintaining them in a stack. The stack is popped and pushed onto (probably maintain a queue for this) as users undo/redo
• Maintain a history of the code written since interaction started. This is easier if we start with an empty scene, but we may also want to consider the scenario in which someone starts with an existing scene and how we represent the original scene versus the scripted code evaluated beyond it

[craigomatic]

I've been doing some thinking on this issue and would like some guidance :)

Client side I have an UndoRedo class that will maintain both an undo stack and a redo stack. When someone clicks undo, I pop the stack and push the undo item to the redo stack, and vice-versa for the redo stack.

In my head, the simplest way to guarantee the correct states during an undo operation will be to:

1. Clear all nodes from the scene
2. Re evaluate all the prior code chunks sequentially from first to last (with the exception of the most recent item in the stack that we'll shift to the redo stack)
3. Undo complete in a slightly inefficient manner...

@ryanvolum when you were giving me the overview of how this should function, I think you mentioned that the prompt stack would need to be cleared out also? Does this imply a similar undo/redo stack should exist server side to maintain the prompt state in sync?

[ryanvolum]

I've been doing some thinking on this issue and would like some guidance :)

Client side I have an UndoRedo class that will maintain both an undo stack and a redo stack. When someone clicks undo, I pop the stack and push the undo item to the redo stack, and vice-versa for the redo stack.

In my head, the simplest way to guarantee the correct states during an undo operation will be to:

1. Clear all nodes from the scene
2. Re evaluate all the prior code chunks sequentially from first to last (with the exception of the most recent item in the stack that we'll shift to the redo stack)
3. Undo complete in a slightly inefficient manner...

@ryanvolum when you were giving me the overview of how this should function, I think you mentioned that the prompt stack would need to be cleared out also? Does this imply a similar undo/redo stack should exist server side to maintain the prompt state in sync?

Per our convo - I think this approach, though less than ideal, is probably the best way to go about it. As for the server side and the prompt, the Context class does expose an undoInteraction functions to pop interactions off of the dialog stack. If we wanted to support redo, we'd want to push undone actions onto a redoStack

[craigomatic]

I've added some code that is partially working on a branch.

It does the following:

1. Calls the undo endpoint that invokes context.undoInteraction();
2. Clears the babylon scene client side
3. Attempts to add all states from the undo stack - 1, back into the scene

I'm having trouble with the 3rd item that I think might be related to timing of the scene recreation. Any pointers on how to wait for the scene to be in a good state?

undoAction in Form.tsx is doing this:

 const undoAction = async (state: IState[]) => {
        resetBabylonScene();
        resetCodexState();

        for(var s of state) {            
            await evalAsync(s);
        }
    }