I have got the hang of writing flux stores - and like the uni-directional dataflow model a lot. I also evaluated relay/graphql - which unfortunately is missing backend support for my relational db for the moment.
It feels like I need some experience with all the patterns/frameworks before it's possible to be confident about choosing and investing time writing code.
Um I guess they both have their place.
Reflux is simpler to understand and forgoes switch statements and has various ways to connect stores up, even allowing one store to trigger stuff on another. It's more easy to make a mess I think, largely dues to the multiple stores and how they interact with eachother.
Redux is more cleanly uni-drectional, has a larger community, amazing debugger, amazing hot reloading support, and a lovely concept of middlewares that can extend actions as they pass through your system. Most importantly I've found a single store/source of truth makes everything cleaner. It's also simpler code underlying it than Reflux and more of a nice design pattern.
I think Redux is clearer what is going on in my final programs and will tend to use this going forward.
The models and collections worked great as "stores" and I used the simple dispatcher from Flux to handle the actions being sent.
While I really like the Flux pattern, for smaller'ish apps it did seem a bit of overkill.
A couple articles I was referencing for BB and React:
https://blog.engineyard.com/2015/integrating-react-with-back... http://www.thomasboyt.com/2013/12/17/using-reactjs-as-a-back...
[1] http://stackoverflow.com/questions/32461229/why-use-redux-ov...
Reflux is Flux but using the environments event model as the dispatcher. It's event based, it's simple, it's easy to get started with. It's not very opinionated, but it doesn't work well on the server (not very isomorphic app friendly).
Redux is the new hotness. It's also very isomorphic app friendly. It's really a "build it from the ground up with this in mind" framework - that's not a bad thing, it just is what it is. It's very smart, but also extremely verbose. Downside - it holds all app state in one giant store. That's... fine, but it actually over-complicates your app if you have a lot of disparate data domains. It's a super opinionated framework.
There's also AltJS which is basically most of the good of Redux but with less of boilerplate. It's way less opinionated than Redux but more so than Reflux.
They all have their pros and cons. Redux is rather over-hyped right now though for what it brings, careful of the hype-train.
React = the view layer.
GraphQL = the store.
Relay = the glue.
I'm still ambivalent on this form of stack but it's a move in the right direction. Component composition makes JS a lot less messy. Meteor is doing something real interesting with isomorphic JS, and whether or not it gets widespread adoption, I'm happy that avenue is being explored as well. Stefan Richter is doing some REAL interesting work with isomorphic Clojure [2] in his shop in Germany, that has some real interesting exercises. The talk is from 2010, so it was more novel when I first watched it than you'd think of today.
Something that Redux doesn't solve is data fetching, caching, and mutations. If you have a reasonably sized application, you'll end up having to implement a lot of logic surrounding data fetching and caching by yourself. The suggested solution is to store your resources normalized, indexed by id, and create selectors to get the data in the shape you want. This works out alright, but it's tedious and during your first few iterations on it you'll probably find yourself with a lot of boilerplate code.
Facebook released Relay [1], which gives you the solution for data fetching and caching. If you give it a try, you'll be amazed by how much mental overhead simply disappears. You want data? You get it, that's it! But then your new problem is that you need a GraphQL server, and since it's a new technology that's not very mature (outside of Facebook at least), it means you'll have to do a reasonable amount of exploring. (I should really clarify that this is in no way the fault of the Facebook teams that put out Relay and GraphQL, both tools are amazing! It's simply that the ecosystems needs time to evolve and adapt.)
I'd say that in one or two years from now a formidable amount of frontend app will be using some variation on Relay and GraphQL.
[0] https://github.com/rackt/redux
[1] https://facebook.github.io/relay/