3 ms·

Going beyond the normal Undo to error/state correction. A lot of JS apps right now just ask a user to refresh the page when something goes wrong. This provides

Going beyond the normal Undo to error/state correction. A lot of JS apps right now just ask a user to refresh the page when something goes wrong. This provides an easier way to get back into a previous working state.

STRML 13y ago
It gets complicated; you have to store the inverse of every API call you use in order to back it out in order to have proper Undo support. IMO the UI is the easiest part of it, as you normally just reuse methods you already use in your app. For example: * Rename model: inverse is to rename back to stored name * Delete model: inverse is to create with same data * Create model: inverse is to delete the model * Add model to collection: inverse is to remove from collection .. and so on. It's pretty simple. I use something similar to JS-Undo-Manager[1] to manage it. Om isn't going to get you around needing to make those calls and your UI should (generally) be able to handle executing the inverse of an action at any time. 1. https://github.com/ArthurClemens/Javascript-Undo-Manager https://github.com/ArthurClemens/Javascript-Undo-Manager
- kibibu 13y ago
  It's not pretty simple though. In particular, if you have any triggers in your API they may need to be deferred until after undo is no longer possible, or have explicit commits. Lets say you have the ability to add a user to a group, and they will get an email about it. You accidentally add your boss to the "I hate my boss" group. How do you support undo in this case? Some sort of timeout before sending is really the only valid approach, but where? One was is to do the deferred part on the client side, but this means closing the browser after adding somebody will mean they won't get notified at all. You really need to have support for undo in the API for this to be meaningful (or the "add to group" api returns a notification ID that you can cancel). As an aside, I'm pretty sure the inverse of deleting a model is typically going to be far more complex than just recreating it. Deleting a social network profile, for example, involves deleting all photos, associations, posts, etc. Easier just to deactivate models so you get easy undo, and periodically flush deactivated objects.
  - STRML 13y ago
    Yes, you're right; I shouldn't have put the "it's pretty simple" statement just a few sentences after "It's complicated" - clearly, depending on the app, undo functionality can get pretty hard to manage, especially when there are emails or complicated relations involved.

STRML 13y ago

It gets complicated; you have to store the inverse of every API call you use in order to back it out in order to have proper Undo support. IMO the UI is the easiest part of it, as you normally just reuse methods you already use in your app. For example: * Rename model: inverse is to rename back to stored name * Delete model: inverse is to create with same data * Create model: inverse is to delete the model * Add model to collection: inverse is to remove from collection .. and so on. It's pretty simple. I use something similar to JS-Undo-Manager[1] to manage it. Om isn't going to get you around needing to make those calls and your UI should (generally) be able to handle executing the inverse of an action at any time. 1. https://github.com/ArthurClemens/Javascript-Undo-Manager https://github.com/ArthurClemens/Javascript-Undo-Manager

kibibu 13y ago
It's not pretty simple though. In particular, if you have any triggers in your API they may need to be deferred until after undo is no longer possible, or have explicit commits. Lets say you have the ability to add a user to a group, and they will get an email about it. You accidentally add your boss to the "I hate my boss" group. How do you support undo in this case? Some sort of timeout before sending is really the only valid approach, but where? One was is to do the deferred part on the client side, but this means closing the browser after adding somebody will mean they won't get notified at all. You really need to have support for undo in the API for this to be meaningful (or the "add to group" api returns a notification ID that you can cancel). As an aside, I'm pretty sure the inverse of deleting a model is typically going to be far more complex than just recreating it. Deleting a social network profile, for example, involves deleting all photos, associations, posts, etc. Easier just to deactivate models so you get easy undo, and periodically flush deactivated objects.
- STRML 13y ago
  Yes, you're right; I shouldn't have put the "it's pretty simple" statement just a few sentences after "It's complicated" - clearly, depending on the app, undo functionality can get pretty hard to manage, especially when there are emails or complicated relations involved.