Can anyone compare and contrast flux, reflux and redux?
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.
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.
I'm using React on a few smaller projects where I didn't want to over engineer the whole Flux architecture. I put together the app using Backbone (for the models and collections) and used React for the view layer.
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:
Flux is just the name of the overall design pattern as well as FB's reference/example of it.
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.
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.