4 ms·

There's two big highlights for me: > Thus we don't need React operations like setState which exists to support both efficient subtree updating as well as good

There's two big highlights for me: > Thus we don't need React operations like setState which exists to support both efficient subtree updating as well as good Object Oriented style. Subtree updating for Om starting from root is always lightning fast because we're just doing reference equality checks all the way down. I don't think anyone actually likes using explicit setters/getters in frameworks like Backbone and Ember. Of course Angular avoids it but that's by the crazy "dirty-checking". Obviously the new Object.observe will help this situation, but I love how simple Om/CLJS makes this. > This also means that Om UIs get undo for free. You can simply snapshot any state in memory and reinstate it whenever you like. It's memory efficient as ClojureScript data structures work by sharing structure. > VCR playback of UI state I can't wait for details on this. This has gotten me really excited about client-side apps again.

DannoHung 13y ago
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.
- jaredly 13y ago
  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.
  - swannodette 13y ago
    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.
porker 13y ago
>> 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?
- bretthopper 13y ago
  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.

DannoHung 13y ago

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.

jaredly 13y ago
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.
- swannodette 13y ago
  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.

porker 13y ago

>> 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?

bretthopper 13y ago
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.