[w01fe]

We're still figuring out exactly where the boundary lies, but our current approach is much like yours -- view state that's purely local to a component goes in local state, and everything else goes in app state. This feels more natural, but means you lose some of the nice benefits of things like replay/undo for this local state.

For client/server, we've started building up some nice abstractions around our API (like fetching more data in a generic paginated list stored in a cursor), but the write side is still mostly manual. We're trying to use the same API for iOS and web, which probably prevents us from doing some fancier things that continue the same architecture back into the server.

[fnordsensei]

So far, I've only made some (large-ish, granted) prototypes with Cljs and Om, but I've run into this as well. I ended up opting out of local state. I put view state and model state in the same atom, but I tried my best to keep them separate within the atom.

Easy replay/undo was one reason. Another reason was that I wanted to be able to take a _complete_ snapshot of the app state, for debugging purposes. A third was that I wanted to keep all the state that a component needs to know in order to render itself in one place, not many places.