-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Undo functionality #10
Comments
After thinking about this for a bit, some issues to address: What goes on the stack?Since the stack will be used for both undoing and incremental saving (each code branch can choose to ignore certain entries), which changes should be on it? It seems logical that computed properties should not be on it, since they are neither saved, nor undone. However, as far as Mavo is concerned, there is no such thing as computed properties. Computed properties are just properties with both If we say that Perhaps it's the intersection of the two that is not on the stack? That seems arbitrary though, and what if the stack is used for other purposes in the future? Or we could just add everything on the stack and depend on each code path to filter out what it doesn't need. The last one probably seems the safest option, though it will bloat the stack. How many stack entries to retain?Should the stack be cleared after each save, or should we just add a special element that means "we saved at this point"? Undoing after save is certainly useful, but incremental saving does need to know when we saved. Never clearing the stack comes with certain performance challenges. Keeping pointers to every node that existed in the lifetime of the app means nothing can ever be garbage collected. So, perhaps it's better to clear the stack after each save, or at least truncate it? How does the undo stack interact with incremental rendering?It looks like any change to the data should be on the stack, even if it's neither undoable, nor saved. Otherwise, references become meaningless. E.g. deleting a collection item might be stored as "delete item at index 3". Now, if incremental rendering happens that adds or deletes items before that index, the entry becomes meaningless. |
After thinking about it some more (and using @svgeesus as my rubber duck 😛), I've decided to proceed in the following way, at least for a first version of this feature:
|
Edit to make this current:
Currently, the only data edit that can be undone is deletion. That is special-cased, implemented via a rather clumsy mechanism that involves a lot of special casing in expressions etc, it’s buggy, increases the amount of stuff that needs to be styled, both by Mavo and by the author, and complicates the eventual data mutation API.
Instead, soft deletion should be abolished, and all data mutations should be added to an undo stack that can be undone and redone via shortcuts and potentially Mavo bar buttons.
This will also make it much easier to implement diff-based (incremental) saving by storage backends, if there is a record of what actions have happened since the last save.
Original text (which doesn’t make any sense now):
The text was updated successfully, but these errors were encountered: