Undo feature with Autobinding

Has anyone been able to implement an undo functionality in their app and would it be possible with an autobinding input field?

If the answer to the above is ‘no’, can anyone offer insight into the advantages of autobinding over ‘when this input value changes’ triggering an update to the DB.

Also, thinking of how I might build and implement a log file for undo…
Maybe I replace the autobinding with ‘when input value changes’
If I create a TaskLog thing and give it a Task field and a text field, then everytime I’m about to make a change to a Task, I write to the TaskLog and capture the Task that’s about to change and a JSON text with the fields and values before the changes. What I don’t know is how to convert that JSON into an Update upon trigger an ‘undo’ workflow.

Seems pretty tedious to do this all over the app. Any thoughts?

Also, how would I handle if I make a change to one task and then delete a different one, and then I want to undo the delete, and then undo the edit? Seems they would have to be handled with different approaches. Is it not possible to have a similar global undo in our app as we have in our app editor?

You’re probably overthinking it a bit, but a shadow copy of the data before it changed is something I’ve built into a bunch of my apps. It would be very rare to need to delete and then undo, etc. One step back suffices in nearly every situation.

I should probably clarify that what I’m doing is fairly complex. I have nested repeating groups going 4 tiers deep. I am able to drag and drop throughout the hierarchy as well as throughout the sort order. Each task has calculated values within itself as well as calculated values up the hierarchy. The UX approach is to keep as few steps as possible to make changes etc. which makes it easy to make mistakes. (ie. no interruptions from warning windows and acknowledgements, which would hinder productive flow for the user) Updated sort orders are interdependent on surrounding tasks. Updated quantities and totals are interdependent on child updated totals. A single change can effect 10’s of records and which records is determined dynamically.

@code-escapee How do you approach your shadow copy and one step back where you have done it?

That does sound complex!

Shadow copy depends on the situation and the number and types of fields. It can be a copy of the thing before changes or storing a number of fields in a new dataset thing or storing overwritten values in a text log list that are extractable…