1. 17
  1.  

  2. 5

    Om’s creator, David Nolen, likes to show off how easy this makes it to implement undo: just remember a of list old states, and you can reset! the state atom to any of them at any time. We liked it for another reason, though: we wanted to serialize the application state so users could send our support team a snapshot of their CircleCI interface. We’d pop in the data they sent, the page would deserialize it and reset! it into the state atom, and—presto-change-o—we’d see exactly what the customer saw.

    I’ve seen the history example before, but in my mind this is a far more compelling example of what state-in-an-atom enables. History doesn’t always make sense in an application, but this sort of debuggability sounds fabulous

    1. [Comment from banned user removed]

      1. 4

        A screenshot can show what actually rendered, but not the data that entered the rendering pipeline. If the problem exists between the application state and the rendering of that state, then a screenshot isn’t nearly as useful as having the actual app state.

        With the data, you can pretty quickly determine if the problem was in rendering, post-rendering (e.g. misbehaving browser plugin), or pre-rendering (malformed data corrupting app state). If it is post-rendering, then you’re at the same point you’d be at with just a screenshot. If it is pre-rendering or in rendering, then you have significantly more information to work with.

        Only in the post-rendering case would you need a VM setup as the user had their machine: any Om app is completely rendered from the app state, so restoring the state sets things up just as they were for the user unless the problem occurs after the render.

        Your point about confidential info is reasonable, though. In CircleCI’s case, I don’t think that its a big concern since any data entered on their pages will likely end up on their servers anyway.

    2. 2

      This is very helpful. I’m just getting started learning the JavaScript library Redux, which also uses a single state atom with React, and I see that Redux’s combineReducers() and connect() basically implement cursors. I always felt wary about using them, and this article explains why: cursors require data to be stored in the same hierarchy as the UI. Thankfully, Redux doesn’t require the use of those functions. I’ll consider using the alternative organization CircleCI describes – passing the whole state to components, and letting them load the paths to their specific data from a centralized file.

      It is also nice to finally get an explanation of the Om Next Quick Start’s mysterious but unexplained phrase, “Unfortunately, cursors brought problems of their own.” Now I finally understand what cursors are and why they aren’t the best abstraction.