A cartoon guide to Flux
medium.com
medium.com
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.
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.
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.
[1] http://stackoverflow.com/questions/32461229/why-use-redux-ov...
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...
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.
Your DB becomes the "dispatcher" and "store", write queries are "actions" and read queries (with change feeds) are the updates from the store to views. And your web page just displays the most recent state.
It makes it easier for sure, but undo/redo isn't dependent on immutability.
"Models pass data to the view layer."
Those who don't understand MVC are bound to reinvent it...and invent fancy new names for it.
EDIT: just in case it wasn't clear, not pushing data from the model to the view, but instead letting the view pull it from the model as needed is pretty much the core feature of MVC.
The issue is when your views start pushing changes to the models and you then jump into a recursive cascade of updates. This is the control-flow equivalent of letting a thousands ping-pong balls loose and trying to predict where each and every one of them will end up.
I don't think its "MVC vs new fancy techs" as you make it sound but rather adding constraints to MVC in order to make it scale.
No. You can only get into a recursive cascade of updates if your model pushes changes to the views in response to changes occurring on the model. Otherwise the two are decoupled.
In a typical MVC app, there are at least two phases: first you react to events and make updates to the model and send out change-notifications that invalidate those parts of the view(s) that represent the bits that have changed. In a second phase, you update the bits of the view(s) that were invalidated. Repeat.
No update cycles, as long as you only invalidate in the first phase, and only repaint in the second phase.
EDIT: The temptation is huge to "optimize" this process by having the invalidation notification do the actual work of repainting. That's where you get into trouble, you need to keep it decoupled.
1. no magic or monkeypatching ( like connect does to container's props)
2. combine/merge make data dependencies much easier to reason about that a single node's state being updated by multiple 'case' statements.
ps: as a poc, I put together a tiny snippet the other night (http://plnkr.co/edit/JIm88A7k7O0TCgfZ0O9f?p=preview).
The best thing about Redux (for me) is the ecosystem. There's tons of active development around middlewares (logging, persistence, routing, etc) and best practices. Its recent popularity means that you really can follow the beaten path and have a sane, performant app.
EDIT: If you're interested in an example React Native/Redux app, you can check out the toy HN reader I'm working on[1]. There are some critical missing features that make it not yet effective as an HN reader, but it's a decent React Native for Android tech demo.
So far I'm using yahoo fluxible as an implementation and it works pretty well in my new isomorphic app.