Are there a lot of details to explain? An immutable data structure means that modifications to the structure tend to be memory cheap. So you save every instance you care about secure in the knowledge that it doesn't waste much space. Then to perform forward or backward operations, you just switch which version you're looking at.

maybe "details" is the wrong way to phrase it. I'm excited to see /a real world implementation/, either proving that it really is that simple, or showing what other complications arise.

I've already played around with some simple prototypes - it works as advertised. There'll be a future blog post showing how it can be done.

>> VCR playback of UI state > I can't wait for details on this. This has gotten me really excited about client-side apps again.

Why? I'm curious what I'm missing about it and the possibilities you see?

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.

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

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.

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.

A bit vague, but this might come in handy in taking screenshots of various states, and using in some sort of visual diffing.