
What the Flux? - skiskilo
http://jonathancreamer.com/what-the-flux/
======
jerf
I'm 100% serious, the "humorous" version makes a ton more sense to me. That
is, totally seriously, some great technical writing in that second diagram.
Going from there to the shorter component names is much easier at that point.
And I'm pretty familiar with this sort of design, but even so, since everybody
has their own names for everything it's still harder to follow the original
diagram. How much worse it would be for someone without experience.

~~~
detaro
I agree. A version of the diagram that showed the official name next to the
description would be a great self-contained small reference.

~~~
jonathancreamer
Here ya go! [http://d.pr/i/14Pi0](http://d.pr/i/14Pi0)

~~~
peri
Heh, yep, that's pretty perfect

------
jefftchan
For me, the part of Flux that's difficult to understand is how server data
flows into the cycle (left-hand side of the diagram). The Flux docs only
recommends that server interactions should be done from the Action Creators.
However, things are actually more complicated than that:

\- how do you resolve server / client data conflicts?

\- how do stores work with a RESTful API?

\- how do you handle network failures, retries, etc?

At Quizlet, we designed a hybrid solution [1] with "syncers" that act as the
gateway for network I/O. Syncers are responsible for taking view-level data
(ViewModels) and exchanging them with the server (ServerModels). It works well
with our REST API. Yahoo has also released their own thing called Fetchr [2]
which is more tightly integrated to stores.

I'm curious to see how other people are approaching this problem.

[1]
[https://news.ycombinator.com/item?id=8954733](https://news.ycombinator.com/item?id=8954733)

[2] [https://github.com/yahoo/fetchr](https://github.com/yahoo/fetchr)

------
rubiquity
I started using React around 0.4 and I would recommend skipping Flux at first
(or entirely) and just learning React. I've helped get a lot of people
interested in checking out React and since Flux has come into existence that
has tripped up just about every single one of them. Flux is just too much, too
soon, and whether you need Flux at all is up for debate.

~~~
teddythetwig
Agreed, although for a different reason. When you start using React.js in your
frontend, you will eventually run into limitations, such as changing data in
sibling components. It is good to know what you can and can't do with React.
Then you get to experience the magic of Flux, and everything that made you
hate React is possible with the combination. It's like eating your vegetables
first... then you get the steak!!

~~~
caseywebdev
> such as changing data in sibling components

[Cursors] can help a lot with this problem. As far as sibling/child components
know, they own the state, but they're really using immutability helpers to
update a larger encompassing state object.

[Cursors]:
[https://github.com/caseywebdev/cursors](https://github.com/caseywebdev/cursors)

------
rdoherty
Slightly off-topic, but I hear about all these awesome new JS frameworks for
tying events and server data to HTML, but what if your app renders nearly
everything to Canvas? I don't need any HTML generation or templates, I just
need a solid events and high-level layouts.

~~~
bengotow
AFAIK, Netflix actually wrote a React "Virtual DOM" => OpenGL renderer. You
don't necessarily have to map the Virtual DOM to a real DOM.

[http://conf.reactjs.com/schedule.html#beyond-the-dom-how-
net...](http://conf.reactjs.com/schedule.html#beyond-the-dom-how-netflix-
plans-to-enhance-your-television-experience)

------
julenx
> So, every component in React has state.

In the context of the article, I know the above text is meant to be a simple
explanation for newcomers, but in the broader context it's worth noting that
having stateful components is not a requirement. Moreover, the lesser state in
a component, the better [1].

[1] [http://facebook.github.io/react/docs/interactivity-and-
dynam...](http://facebook.github.io/react/docs/interactivity-and-dynamic-
uis.html#what-components-should-have-state)

~~~
jcreamer
Great point. Thanks.

------
speg
I've been using React for a while and love it. Every time I tried to look at
Flux I got put off by something or other. I get the main concept, Actions
coming from your React Views are Dispatched. But the first tutorial starts
with writing your own dispatcher from scratch which I think was the thing that
threw me. Flux.js does have a dispatcher you can use out of the box, so why
not just use that when starting off.

~~~
reczy
I started using marty.js [1] after it popped up on HN a few days ago [2]. The
documentation is outstanding and includes guides/explanations of the
architecture beyond just an api reference.

[1] [http://martyjs.org/](http://martyjs.org/) [2]
[https://news.ycombinator.com/item?id=8923053](https://news.ycombinator.com/item?id=8923053)

~~~
jordonwii
+1 for Marty. I'd never used Flux before, but had made some small apps in
React and felt pretty comfortable with it. The Marty docs have a particularly
good description (with small examples) of what each piece of the Flux model is
supposed to do. After following those and making a toy project, I actually
felt like I'd wrapped my head around the basics of Flux+React pretty firmly.

------
rtorr
Make the investment to learn Flux if you are using React. Now that we have had
Flux in production for a few months, I think have React without Flux is a
handicap. I think reading about it is harder than just building something with
it. My advice? Build something small with it, and you will at least know Flux.
Then you can decide to use it or not. We use facebook's flux implementation,
and have no regrets.

------
highpixels
I've never quite understood Flux, partly due to all the cruft & boilerplate
involved around Actions & Action Creators.

I've found a Command Bus pattern (a la CQRS) works much nicer, and cleaner.

1\. Something happens in View (e.g. todo item is checked) 2\. View passes a
"CompleteTodoItemCommand" object to the Command Bus 3\. Command Bus dispatches
the Command to a registered Handler 4\. Handler communicates with server,
store etc. to handle the command; handing TodoItem to the store 5\. Store
triggers change event 6\. View hears change event, renders self

That said, I've only built a few smaller projects in React, so perhaps I'm
missing something important which Flux solves and I'm missing?

~~~
lobster_johnson
That's exactly how we build our Flux apps. We follow, roughly, the Flux naming
patterns -- your "bus" is the dispatcher, "handler" is the store's dispatch
handler, everything else is the same -- but we left out the action creator
thingies and instead direct actions directly to stores and let them do the
data state management.

------
billsimpson
This is a bit off topic, but whenever I'm tempted to add React to a page or
incorporate it into my single page app, I keep asking: is it worth roughly
doubling the size of my javascript payload (130 kB React + 96 kB jQuery for
AJAX + X kB business logic)?

I keep backing off, and sticking with jQuery/Backbone. One solution would be
using a lightweight AJAX library in place of jQuery, but I haven't found one
that is widely used, well maintained, and recommended. Can anyone recommend
one?

Or in 2015 should an extra 130 kB be considered a non-issue?

~~~
caseywebdev
I'm a fan of [superagent] for AJAX. The React lib is big, but its declarative
nature has lead to fewer and easier-to-diagnose bugs for us, which is
ultimately a win for the end user. I've been using it exclusively on new
projects for months now and I'm a Backbone.js core contributor ;)

superagent:
[https://github.com/visionmedia/superagent](https://github.com/visionmedia/superagent)

~~~
nogridbag
I've been toying with mercury, which is similar to React/flux, and had the
same dilemma as the parent. It seems a bit strange to use a really light
weight library like mercury and then throw jQuery into the mix.

I also checked out superagent and it seems to have a good amount of
dependencies. I was thinking of simply wrapping XMLHttpRequest with the
promise lib of my choice.

This link seems relevant...
[http://youmightnotneedjquery.com](http://youmightnotneedjquery.com)

------
jlees
_When I look at the docs and blog posts about Flux, and React, my brain
goes.._

What did you do to get your head around it, if the docs are not so accessible?
Just build stuff until it the pieces start to fall into place?

~~~
danesparza
" Just build stuff until it the pieces start to fall into place?"

That's exactly what I had to do. It's much easier to understand WHY certain
parts of Flux were put in place once you start to use them in a larger app.

Deconstruct one of the Facebook examples (I'd recommend the todo app) and see
how data is passed around. I had several light-bulb moments doing this.

Also: It helps to understand commonJS and a bit of node -- specifically what
they use Browserify for.

------
goatslacker
Very nice, this is a great write up on an intro to flux. It feels like a lot
of the learning curve on flux is spent trying to figure out exactly where to
query data: in the actions, the store, or utils? And I feel like most of the
pain in starting flux from scratch is creating all the constants, action
creators, and registering the dispatcher.

After you've got everything set up it's smooth sailing though and you live
with no regrets. Getting up that first hill though is tough.

I like thinking of my actions as where I fire off everything that will be
fetching data. Then I keep the stores synchronous so that their only job is to
get data from the dispatcher and store it. This makes the whole application
pretty easy to reason about.

------
PhrosTT
Awesome post man. People often overcomplicate simple concepts wayyyy too much.

~~~
chadpaulson
Agreed. There are many labyrinthian Flux libraries and examples out in the
wild. The most simple, and underrated, Flux implementation I have come across
is Alt -
[https://github.com/goatslacker/alt](https://github.com/goatslacker/alt).

------
highace
I only just got my head around angular, and now flux + react have come along
and wrecked the party.

~~~
chadpaulson
I was you ~6-7 months ago. My biggest motivation for evaluating and eventually
working with React was its simple philosophy. With it comes a lot of power.
The ability to create an accessible application that rendered on the client
and server side and didn't even require Javascript in the client to function.
[https://github.com/chadpaulson/react-isomorphic-video-
game-s...](https://github.com/chadpaulson/react-isomorphic-video-game-search)

------
aturek
Topical and recent: [https://www.nilas.com/blog/splitting-the-
atom](https://www.nilas.com/blog/splitting-the-atom) (some more talk about
people using Flux)

------
illicium
MVC with an event bus (I mean, um, "Flux") is about as far from "computer
science" as you can get. Software engineering, maybe.

~~~
baddox
Software engineering is a topic in the field of computer science, namely
applied computer science. You might be using "computer science" to refer to
"theoretical computer science."

------
jonathancreamer
@detaro, here's a version of the image with original and my modified version

[http://d.pr/i/14Pi0](http://d.pr/i/14Pi0)

------
mey
This reminds me of looking at JSF

