automerge-classic
automerge-classic copied to clipboard
automerge
Bring back the undo feature
For the Automerge 1.x release series we have removed the undo/redo feature, since the old implementation was a hack that didn't work very well and that we didn't want to support long-term. However, undo remains a useful feature, and this issue is our task to bring it back, done properly this time.
Some ideas for things to keep in mind when designing the new undo:
- By default, Ctrl-Z-style undo should only undo changes made by the local user (we may want a separate "revert" feature for undoing other users' changes).
- Undo history should persist even when a document is saved to disk and later loaded back into memory. However, saving and reloading by default changes the actorId — how do we identify the changes made by the local user?
- Have a way of excluding certain updates from the change history. For example, in a Jupyter notebook, the CRDT may contain both user input (source code, text) and machine-generated output (the result of running a piece of code). When the machine-generated output is updated, we may not want to record that in the undo history, allowing the undo history to focus on the user input only.
- Have sensible handling of move operations (see #247)
- Figure out desired behaviour when a mixture of text insertions and deletions are undone (see #216)
Hi @ept
for example, in a Jupyter notebook, the CRDT may contain both user input (source code, text) and machine-generated output (the result of running a piece of code). When the machine-generated output is updated, we may not want to record that in the undo history, allowing the undo history to focus on the user input only.
For jupyter, we can manage the exclusion of outputs and ensure they are not within CRDT. This is a nice feature but not a requirement in the short term for Jupyter.
The undo of move operations is however a must for this.
What kind of timeline are you seeing for a first implementation with the basic features?
Reverting my previous comment on excluding certain updates from the change history. I said this we would need that in first instance as we would not manage the outputs in CRDT.... however we would be managing some metadata of the notebook (language...), and avoiding undoing actions on metadata would be a great feature.
I don’t know about any updates but a 'workaround' is to keep a local undo history outside of Automerge. This is less complex than you may think, but you probably do want to model user interactions as events (or 'actions' / 'operations' / 'updates' whatever you want to name them). So basically wou will have a small abstraction layer between your UI and Automerge: You can have a central update function where your event comes in and where you push it to the local undo history. From there you also call the Automerge change function and makes changes based on the event (similar to a reducer function in React or Redux, but here with a mutable API).
The trick is to update the current event in the local undo history at the moment of undo/redo, based on the current corresponding value in the application state (in this case the Automerge document). It is visually explained in this Figma blog article. I think that it does not matter if you use a client-server or a p2p architecture. The local undo history has nothing to do with sync. Of course you can bypass Automerge entirely and sync your own events, but then you will need to implement all the smarts (eventual consistency) yourself.
I’ve been playing around with this undo/redo model a while ago in my spare time. See this experimental lib and this interactive demo. Again this is all hobby stuff and not used in an actual project, and neither in combination with Automerge or a p2p setting.
