
A cartoon guide to Flux - snehesht
https://medium.com/code-cartoons/a-cartoon-guide-to-flux-6157355ab207
======
TheAceOfHearts
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.

[0] [https://github.com/rackt/redux](https://github.com/rackt/redux)

[1] [https://facebook.github.io/relay/](https://facebook.github.io/relay/)

~~~
stream_fusion
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.

~~~
andy_ppp
I have used both Reflux and Redux.

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.

------
JulianMorrison
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.

------
mynegation
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?

~~~
KurtMueller
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).

------
sktrdie
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](https://www.youtube.com/watch?v=jWq_3EH_mpg&feature=youtu.be)

~~~
robmcm
> This allows to do really cool things such as undo/redo of actions.

It makes it easier for sure, but undo/redo isn't dependent on immutability.

~~~
andy_ppp
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.

~~~
gambler
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.

~~~
andy_ppp
Sounds prone to bugs and very slow to me.

------
mpweiher
You kind of had me at

"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.

~~~
jeremiep
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.

~~~
mpweiher
>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.

------
findjashua
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.

ps: as a poc, I put together a tiny snippet the other night
([http://plnkr.co/edit/JIm88A7k7O0TCgfZ0O9f?p=preview](http://plnkr.co/edit/JIm88A7k7O0TCgfZ0O9f?p=preview)).

------
valisystem
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.

~~~
myko
Is KVO common in JavaScript? I've only ever used it in the Cocoa realm.

~~~
debacle
IMHO a KVO programming style in JavaScript would be very error prone since
there's no typing.

------
cocoflunchy
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).

~~~
cel1ne
Go for Redux instead: [http://teropa.info/blog/2015/09/10/full-stack-redux-
tutorial...](http://teropa.info/blog/2015/09/10/full-stack-redux-
tutorial.html)

------
drinchev
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.

------
danvesma
didn't get to the end, but your writing and graphic style are excellent and
very readable

