A Cartoon Guide To Flux – Code Cartoons
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 12
12/9/2018 A cartoon guide to Flux – Code Cartoons
https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207 1/12
LinClark Follow
Stungmyheadwithcode,thenturningitinto@codecartoons
Sep29,2015 ·9minread
AcartoonguidetoFlux
Flux is both one of the most popular and one of the least understood
topics in current web development. This guide is an attempt to explain
it in a way everyone can understand.
Theproblem
First, I should explain the basic problem that Flux solves. Flux is a
pattern for handling data in your application. Flux and React grew up
together at Facebook. Many people use them together, though you can
use them independently. They were developed to address a particular
set of problems that Facebook was seeing.
One really well known
example of this set of
problems was the notication
bug. When you logged in to
Facebook, you would see a
notication over the messages
Otherlanguages: , , .
Imageshaven’tloadedyet.Pleaseexitprinting,waitforimagestoload,andtryto
printagain.
12/9/2018 A cartoon guide to Flux – Code Cartoons
https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207 2/12
icon. When you clicked on the messages icon, though, there would be
no new message. The notication would go away. Then, a few minutes
later after a few interactions with the site, the notication would come
back. You'd click on the messages icon again… still no new messages. It
would just keep going back-and-forth in this cycle.
It wasn’t just a cycle for the
user on the site. There was
also a cycle going on for the
team at Facebook. They would
x this bug and everything
would be ne for a while and
then the bug would be back. It
would go back-and-forth between being resolved and being an issue
again.
So Facebook was looking for a way to get out of this cycle. They didn’t
want to just x it once. They wanted to make the system predictable so
they could ensure that this problem wouldn’t keep resurfacing.
Theunderlyingproblem
The underlying problem that they identied was the way that the data
owed through the application.
Note: this is what I’ve gleaned from simplied versions that they’ve shared
in talks. I’m sure the actual architecture looked dierent.
They had models which held
the data and would pass data
to the view layer to render the
data.
Because user interaction
happened through the views,
the views sometimes needed
to update models based on
user input. And sometimes
models needed to update other models.
On top of that, sometimes these actions would trigger a cascade of
other changes. I envision this as an edge-of-your-seat game of Pong —
it’s hard to know where the ball is going to land (or fall o the screen).
Modelspassdatatotheviewlayer.
12/9/2018 A cartoon guide to Flux – Code Cartoons
https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207 3/12
Throw in the fact that these
changes could be happening
asynchronously. One change
could trigger multiple other
changes. I imagine this as
throwing a whole bag of ping-
pong balls into your Pong
game, with them ying all
over the place and crossing
paths.
All in all, it makes for a hard to
debug data ow.
Thesolution:unidirectionaldataow
So Facebook decided to try a dierent kind of architecture, where the
data ows in one direction — only one direction — and when you need
to insert new data, the ow starts all over again at the beginning. They
called their architecture Flux.
This is actually really cool… but you probably can’t tell it from the
diagram above.
Once you understand Flux, this diagram is pretty clear. The problem is
that if you’re coming to the documentation completely new to Flux, I
don’t think that this diagram helps you understand it… and that’s what
a diagram should do. It should give you a big picture understanding of
a system before you dive in to really start guring out how you do
specic things.
What helped me understand Flux better wasn’t a diagram like this, but
instead thinking of the system in terms of dierent characters working
together as a team to achieve a goal. So I want to introduce you to the
cast of characters that I have in my head.
Viewsupdatemodels.Modelsupdateother
models.Thisstartstolooklikeareallyedge-of-
your-seatgameofPong.
Thediagramyou’llndinFacebook’sFluxdocs.Itiswaycoolerthanitlooks.
12/9/2018 A cartoon guide to Flux – Code Cartoons
https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207 4/12
Meetthecharacters
I’m just going to give a quick introduction to the characters before I
explain how they all interact.
Theactioncreator
The rst character is the action creator. It’s in charge of creating
actions, which is the path that all changes and interactions should go
through. Whenever you want to change the state of the app or have the
view render dierently, you shoot o an action.
I think of the action creator as
a telegraph operator. You go to
the action creator knowing
basically what message you
want to send, and then the
action creator formats that in
a way that the rest of the
system can understand.
The action creator creates an
action with a type and a
payload. The type will be one of the types that you have dened as
actions in your system (usually a list of constants). An example of an
action would be something like MESSAGE_CREATE or
MESSAGE_READ.
There’s a neat side eect to having a part of your system that knows all
of the possible actions. A new developer can come on the project, open
up the action creator les and see the entire API — all of the possible
state changes — that your system provides.
Once it has created the action message, the action creator passes that
action o to the dispatcher.
Thedispatcher
The dispatcher is basically a big registry of callbacks. It’s kind of like a
telephone operator at a phone switchboard. It keeps a list of all of the
stores that it needs to send actions to. When an action comes in from
the action creator, it will pass the action around to dierent stores.
It does this in a synchronous way, which helps with that multi-ball
Pong game eect that I was talking about earlier. And if you need to set
Theactioncreatorislikeatelegraphoperator.It
formatsyourmessageforyou.
12/9/2018 A cartoon guide to Flux – Code Cartoons
https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207 5/12
up dependencies between
stores so one gets updated
before the other, you can have
the dispatcher manage this for
you with waitFor().
The Flux dispatcher is
dierent from dispatchers in
many other architectures. The
action is sent to all of the
registered stores regardless of
what the action type is. This
means the store doesn’t just
subscribe to some actions. It
hears about all actions and lters out what it cares about and doesn’t.
Thestore
Next is the store. The store holds on to all state in the application, and
all of the state changing logic lives inside of the stores.
I think of the store as an over-
controlling bureaucrat. All
state changes must be made
by it personally. And you can’t
directly request that it change
the state. There are no setters
on the store. To request a state
change, you must follow
proper procedure… you must
submit an action via the action
creator/dispatcher pipeline.
As I mentioned above, if a store is registered with the dispatcher, all
actions will be sent to it. Inside the store there’s usually a switch
statement that looks at the action type to decide whether or not this
store cares about this action. If the store does care about this action, it
will gure out what change needs to be made based on this action and
update the state.
Once the store has made its changes to the state, it will emit a change
event. This will notify the controller view that the state has changed.
Thecontrollerviewandtheview
Thedispatcherislikeaswitchboardoperator.It
knowsallthecallbacksforthedierentstores.
Thestoreisanover-controllingbureaucrat.All
changesmustgothroughit.
12/9/2018 A cartoon guide to Flux – Code Cartoons
https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207 6/12
The views are in charge of taking the state and rendering it out for the
user as well as accepting user input.
The view is a presenter. It isn’t
aware of anything in the
application, it just knows the
data that’s handed to it and
how to format the data into
output that people understand
(via HTML).
The controller view is like a
middle manager between the
store and the view. The store
tells it when the state has
changed. It collects the new
state and then passes the
updated state along to all of
the views under it.
Howtheyallworktogether
So let’s take a look at how all of these characters work together.
Thesetup
First there’s the setup: application initialization which only happens
once.
1. Stores let the dispatcher know that they want to be notied
whenever an action comes in.
Thecontrollerviewislikeamiddlemanagerwho
getsnoticationsfromthestoreandpassesthe
dataontotheviewsunderit.Theviewpresents
thatdatatotheuser.
12/9/2018 A cartoon guide to Flux – Code Cartoons
https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207 7/12
2. Then the controller views ask the stores for the latest state.
3. When the stores give the state to the controller views, they pass that
state along to their child views to render.
4. The controller views also ask the stores to keep them notied when
state changes.
Thedataow
Once the setup is done, the application is ready to accept user input. So
let’s trigger an action by having the user make a change.
We’ll kick o the data ow with a user interaction.
12/9/2018 A cartoon guide to Flux – Code Cartoons
https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207 8/12
1. The view tells the action creator to prepare an action.
2. The action creator formats the action and sends it o to the
dispatcher.
12/9/2018 A cartoon guide to Flux – Code Cartoons
https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207 9/12
3. The dispatcher sends the action o to the stores in sequence. Each
store gets notied of all actions. Then the store decides whether it cares
about this one or not, and changes the state accordingly.
4. Once it’s done changing state, the store lets its subscribed view
controllers know.
5. Those view controllers will then ask the store to give them the
updated state.
6. After the store gives it the state, the view controller will tell its child
views to rerender based on the new state.
12/9/2018 A cartoon guide to Flux – Code Cartoons
https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207 10/12
So that’s how I think of Flux. Hope it helps!
...
Comingupnext…
AcartoonintrotoRedux-CodeCartoons
Onethingthatcausesevenmoreconfusionthan
FluxisthedierencebetweenFluxandRedux,a…
code-cartoons.com
Resources
Flux documentation
Fluxxor documentation
The Case for Flux
Thank you to the fantastic Kent C. Dodds, Matt Zabriskie, and Christopher
Chedeau for their early feedback, and to all the folks at BrooklynJS for
•
•
•
12/9/2018 A cartoon guide to Flux – Code Cartoons
https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207 11/12
their comments on the live action version!
12/9/2018 A cartoon guide to Flux – Code Cartoons
https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207 12/12
