Another commenter mentioned it, but I'm going to +1 using Redux [0] as well. If you need to pick up a framework, Redux is a great choice to consider, it's tiny and very simple. It pushes you towards keeping a lot of your business logic as pure JS, so testing your code tends to be really easy (and it means your code is re-usable, it's not tied super tightly to X or Y framework!). If you use it with React it's also a joy to test.
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.
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.
Is there any decent framework that combines the models used by these technologies all into one? It seems a bit unwieldy to have to juggle between React, Redux, and Relay, while also throwing GraphQL into the mix.
Relay is basically the framework that brings everything together. Relay handles data fetching, storage, and mutations using a central store and GraphQL. If I'm understanding it correctly, Redux is replaced by Relay.
Yeah, in the GraphQL lectures the FB presenters basically said. [1] Watch the first ten minutes if nothing else.
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.
If you're willing to wait for JSON to schlep to the server and query updates to schlep back, using the change feed feature on RethinkDB gives you this with essentially no boilerplate.
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.
On a high-level, I am still struggling to understand the real difference between two-way data flow and unidirectional data flow. Sure, it is actions, and dispatchers, and stores, but if you collapse them into one block, it is still two-way. What is possible with this setup that two-way data flow could not do?
Well, for one, you don't have to rely on observers/watchers anymore. You also don't have to pass functions back up scopes/templates/components. It's also really easy to keep your code organized (since data can only go one direction, in a big circle, it's much easer to follow the flow of logic).
Redux to me is the most exciting part of patterns like Flux. Specifically the idea of immutable state where to change the state you replace the current state with a new object. This allows to do really cool things such as undo/redo of actions. Check this simple video out to understand the power of Flux + immutable state: https://www.youtube.com/watch?v=jWq_3EH_mpg&feature=youtu.be
It's much more complicated to build a system that can do undo without immutability IMO. Redux requires that you never mutate the global state object and things tends to be faster on large numbers of operations/clonings if you use something like Immutable.js.
You could store your state in DOM and serialize the entire page. Not very elegant, but it works and is relatively straightforward. Although, the mental leap required to represent your state via attributes is probably higher for most devs than even immutable data structures.
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.
That's not the issue. Whether its being pushed or pulled isn't relevant at all either.
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.
>The issue is when your views start pushing changes to the models and you then jump into a recursive cascade of updates.
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.
I really like the philosophy of Redux (app state in a single object, pure components w only props, no state), but still think implementing this idea with observables would lend a couple extra benefits:
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.
To those who don't want to be tied to a specialized library, you can architect an app like that way (unidirectional data flow) quite easily if you use KVO properly.
I haven't tried using Flux yet as I haven't really felt the need... Does anyone have insight on how to use it with React Native? Do you have a single action creator / dispatcher for your whole app? It feels messy since my screens in the app are usually pretty independent (but maybe I haven't written a complex enough app yet... hard to tell).
I recommend redux, like sibling commentor cel1ne. You should just use a single store for everything, as is recommended in the Redux docs, and then if a particular view of your app only needs a subset of all the data, just "connect" it to the subtree that's relevant using react-redux. I use it with React Native and it works great. Just be sure to use the react-redux instructions for React Native.
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.
I still remember the first day when I decided to check out "Flux", I was googling for half a day, before I realise that it's "just an idea" how to manage your application flow.
So far I'm using yahoo fluxible as an implementation and it works pretty well in my new isomorphic app.
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/