This structure is great if you're mostly concerned with letting data flow through your application and less with transactional guarantees. It's easy to imagine how this architecture can apply to a chat or a Facebook-style wall or river of user-provided content.
I'm not convinced that this is a useful architecture for applications that aren't primarily about streams of user-created content. React's idea of unidirectional data flow and a strictly linear hierarchy (which is frequently subverted by "Flux" libraries via global stores) is powerful and IMO far more widely applicable than the Flux architecture in which it is frequently used.
I think a cross-breed of Flux's concept of actions and stores and the traditional MVC style collections and models might be worth exploring. This is where our internal React code seems to be heading, anyway.
Shameless plug/disclosure: I'm the author of Fynx (http://foss-haas.github.io/fynx/) which started out as yet another Flux library and is currently undergoing a rewrite in our internal code which will become the 2.0 release once it has stabilised.
Looking at my comment history there is a disturbing trend: off-the-cuff sarcastic quips get upvoted to the double digits (with a few sub-zero exceptions depending on who else is reading the comments), serious attempts of having a discussion get downvoted or not voted on at best. So much for "HN is not Reddit".
For smallish amounts of content, re-querying the entire dataset out of pouch every time a change happens works fine.
For tables with e.g. several thousand rows, I started to need an explicit cache however, and update it with only the changed documents.
http://martinfowler.com/eaaDev/EventSourcing.html https://msdn.microsoft.com/en-us/library/jj554200.aspx
Maybe I should ask before stating: What was the intention of coupling your store and action in this scenario?
