As far as I understand Flux (I'm wondering if "understanding Flux" is becoming 2015's "understanding Monads"), in its pure form it is based on the idea that state is an aggregate of past actions. In other words, the database becomes more of a message queue (or event log) and the "models" are simply cached aggregates.

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.