To me it feels like they are both trying to solve the problem of modifying state in a react app. Flux is probably more manual, by explicitly creating actions that modify state in a store that is listened to by components. With these cursor type solutions you pass down pieces of state through the component hierarchy (not outside of it as in flux's case), mutating the data as needed. Maybe it's useful to think about flux as being action centric, and cursors data centric? I'm still wrapping my head around Flux and am not entirely convinced its a good thing yet.

I'd love some input from users of om or one of the pure js solutions how it works for them. For example, how would one go about monitoring state outside of a component? Think submitting analytics events when a user does something.

Apologies for my naïveté but what you're saying is that you would either use Flux or some cursor based solution, but they wouldn't work together? I'm still getting into this but I'm very curious as I'd like to architect something robust and it seems this piece of React apps is very much in... flux. What are your thoughts on future-proof and ease of use for each solution?

I'm not really concerned about React-specific implementation, but rather a data structure that serves as a facade over the storage layer (either a remote server or the storage systems made available to the browser). This way the UI (e.g. React components and other view-like things) just talks to this facade and doesn't have to know anything about the network, its availability, or browser-specific storage options.

Mozilla's localForage is a good tool specifically for abstracting away the client-side storage mechanism from the UI logic. Aside from that I have looked at Flux and its stores would be the place where you would implement such a facade.

I've used PouchDB this way in the past, and it worked well for seamlessly enabling offline use/hiding network concerns from the view layer, but it's probably a lot "thicker" than what you have in mind (and isn't completely browser-proof, and requires the server storage to look like a CouchDB).

It's interesting to imagine what the lighter facade you're describing might look like. I guess you'd want the controllers/views to get a key-value style interface, and you'd want the facade to connect with one or more local storage options, and some sort of logic to manage triage between local and remote storage, and syncing between the two, and a well-defined API for connecting the remote storage. Hmmm...

Well, Fb gave a presentation that said interaction with their web utils (so storage if you want to call it that) actually happens in the action itself, with pending, success and failure "actions" (events really) being dispatches to the stores. Not sure what that means for your facade, but it's confusing the hell out of me. What is the store supposed to do? Just hold onto the state, period?

not sure if i am following you, but in my apps, the data is always in React state. Whether it came from network or from localstorage is irrelevant. There is some code somewhere that loads data into React state from whatever source. All react is doing is rendering views as a fn of state.