22 ms·

What the Flux?

168 points by skiskilo 12y ago

PhrosTT 12y ago
Awesome post man. People often overcomplicate simple concepts wayyyy too much.
- jcreamer 12y ago
  Thanks! I had fun writing it and learning flux. :)
- chadpaulson 12y ago
  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 12y ago
I only just got my head around angular, and now flux + react have come along and wrecked the party.
- jcreamer 12y ago
  lol, I hear ya
- chadpaulson 12y ago
  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-search https://github.com/chadpaulson/react-isomorphic-video-game-s...
- vertex-four 12y ago
  React is simple - at its core, it's a pile of functions that return the expected state of the DOM, along with event handlers. Flux seems slightly overly complicated for a lot of uses (i.e. if you're not building a massive interdependent single-page app on the scale of Facebook or GMail), and if you have no issue with MVC, you can just use an MVC paradigm with React as the view.
jlees 12y ago
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?
- jcreamer 12y ago
  I built a few small things and these examples really helped... https://github.com/facebook/flux/tree/master/examples/ https://github.com/facebook/flux/tree/master/examples/
- aggronn 12y ago
  I think reading through Flux framework documentations (marty's for instance) helps a lot. They do some abstracting on top and let you avoid some more in-depth questions about how to implement framework level features. They offer you some classes, and you just implement the classes to model the high level ideas of Flux.
- danesparza 12y ago
  " 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.
rubiquity 12y ago
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 12y ago
  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 12y ago
    > 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
- mercer 12y ago
  Alternatively, you could use Reflux.js[1] for a simplified Flux-implementation that is probably enough for smaller apps. I use it in combination with React.js, or Ractive.js, depending on my or my client's needs. Ractive.js, which uses mustache templates, is particularly useful if one needs to collaborate with people who cannot use JSX or are wary of it. And it's pretty useful for smaller projects too. [1]: https://github.com/spoike/refluxjs https://github.com/spoike/refluxjs
  - rashkov 12y ago
    There is actually an html to jsx compiler available [1]. I've had good luck using it against HTML templates that were handed to me by a designer. [1] http://facebook.github.io/react/html-jsx.html http://facebook.github.io/react/html-jsx.html
mey 12y ago
This reminds me of looking at JSF
jerf 12y ago
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.
- jcreamer 12y ago
  Great! Glad it helped.
- platz 12y ago
  I wonder if the problem is that names like "action","dispatcher","view" are abstractions that no longer (if ever) have a meaningful precise definition that can be understood independent of context in an application/framework. I'll refrain pointing at other examples from elsewhere. These terms seem like nice jargon to shorten discussions among people who already understand everything and just want to communicate quickly, but I don't think they help those outside who want to learn. I have no idea what the solution is since jargon probably can't be avoided, but perhaps my request would be that folks understand that the semantic meaning of these terms are not transportable across different domains; they are not self-evident and should not be expected that learners will infer good enough meaning from the term alone.
- detaro 12y ago
  I agree. A version of the diagram that showed the official name next to the description would be a great self-contained small reference.
  - jcreamer 12y ago
    I'll see what I can do. :)
  - jonathancreamer 12y ago
    Here ya go! http://d.pr/i/14Pi0 http://d.pr/i/14Pi0
speg 12y ago
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.
- chadpaulson 12y ago
  I suggest having a look at Alt. https://github.com/goatslacker/alt https://github.com/goatslacker/alt
- reczy 12y ago
  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 12y ago
    +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.
rdoherty 12y ago
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.
- chadpaulson 12y ago
  Valid question. React is actually a UI library, not a framework, and is suited to work with multiple view "backends" including canvas. https://facebook.github.io/react/blog/2013/06/05/why-react.html https://facebook.github.io/react/blog/2013/06/05/why-react.h...
- iamsaul 12y ago
  react-three [1] is a great example of using React to control something other than 'standard HTML'. [1] https://github.com/Izzimach/react-three https://github.com/Izzimach/react-three
- bengotow 12y ago
  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-netflix-plans-to-enhance-your-television-experience http://conf.reactjs.com/schedule.html#beyond-the-dom-how-net...
aturek 12y ago
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 12y ago
MVC with an event bus (I mean, um, "Flux") is about as far from "computer science" as you can get. Software engineering, maybe.
- baddox 12y ago
  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."
billsimpson 12y ago
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?
- aturek 12y ago
  If you use a CDN (or use the public CDNs that many of these libraries have) it's not 130 kb, it's a network request + 304
  - billsimpson 12y ago
    Yes. The issue for me has been that I bundle my libraries with my app using, for instance, Browserify. So whenever I update the app (which is fairly often), the entire bundle needs to be redownloaded by all clients. I guess the obvious solution is to unbundle the larger libraries that don't get updated frequently.
    - cshenoy 12y ago
      That is absolutely the solution. Don't bundle jQuery and other big libraries into your application code. It can drastically improve performance.
      - billsimpson 12y ago
        In that case, must you create one or more separate bundles to contain your vendor libraries? I suppose there's no way to directly integrate a jQuery library hosted on a public CDN.
- caseywebdev 12y ago
  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
rtorr 12y ago
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.
jefftchan 12y ago
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
julenx 12y ago
> 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-dynamic-uis.html#what-components-should-have-state http://facebook.github.io/react/docs/interactivity-and-dynam...
- jcreamer 12y ago
  Great point. Thanks.
jonathancreamer 12y ago
@detaro, here's a version of the image with original and my modified version http://d.pr/i/14Pi0 http://d.pr/i/14Pi0
highpixels 12y ago
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 12y ago
  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.
goatslacker 12y ago
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.

What the Flux?

168 points by skiskilo 12y ago

PhrosTT 12y ago

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

jcreamer 12y ago
Thanks! I had fun writing it and learning flux. :)
chadpaulson 12y ago
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 12y ago

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

jcreamer 12y ago
lol, I hear ya
chadpaulson 12y ago
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-search https://github.com/chadpaulson/react-isomorphic-video-game-s...
vertex-four 12y ago
React is simple - at its core, it's a pile of functions that return the expected state of the DOM, along with event handlers. Flux seems slightly overly complicated for a lot of uses (i.e. if you're not building a massive interdependent single-page app on the scale of Facebook or GMail), and if you have no issue with MVC, you can just use an MVC paradigm with React as the view.

jlees 12y ago

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?

jcreamer 12y ago
I built a few small things and these examples really helped... https://github.com/facebook/flux/tree/master/examples/ https://github.com/facebook/flux/tree/master/examples/
aggronn 12y ago
I think reading through Flux framework documentations (marty's for instance) helps a lot. They do some abstracting on top and let you avoid some more in-depth questions about how to implement framework level features. They offer you some classes, and you just implement the classes to model the high level ideas of Flux.
danesparza 12y ago
" 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.

rubiquity 12y ago

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 12y ago
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 12y ago
  > 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
mercer 12y ago
Alternatively, you could use Reflux.js[1] for a simplified Flux-implementation that is probably enough for smaller apps. I use it in combination with React.js, or Ractive.js, depending on my or my client's needs. Ractive.js, which uses mustache templates, is particularly useful if one needs to collaborate with people who cannot use JSX or are wary of it. And it's pretty useful for smaller projects too. [1]: https://github.com/spoike/refluxjs https://github.com/spoike/refluxjs
- rashkov 12y ago
  There is actually an html to jsx compiler available [1]. I've had good luck using it against HTML templates that were handed to me by a designer. [1] http://facebook.github.io/react/html-jsx.html http://facebook.github.io/react/html-jsx.html

mey 12y ago

This reminds me of looking at JSF

jerf 12y ago

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.

jcreamer 12y ago
Great! Glad it helped.
platz 12y ago
I wonder if the problem is that names like "action","dispatcher","view" are abstractions that no longer (if ever) have a meaningful precise definition that can be understood independent of context in an application/framework. I'll refrain pointing at other examples from elsewhere. These terms seem like nice jargon to shorten discussions among people who already understand everything and just want to communicate quickly, but I don't think they help those outside who want to learn. I have no idea what the solution is since jargon probably can't be avoided, but perhaps my request would be that folks understand that the semantic meaning of these terms are not transportable across different domains; they are not self-evident and should not be expected that learners will infer good enough meaning from the term alone.
detaro 12y ago
I agree. A version of the diagram that showed the official name next to the description would be a great self-contained small reference.
- jcreamer 12y ago
  I'll see what I can do. :)
- jonathancreamer 12y ago
  Here ya go! http://d.pr/i/14Pi0 http://d.pr/i/14Pi0

speg 12y ago

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.

chadpaulson 12y ago
I suggest having a look at Alt. https://github.com/goatslacker/alt https://github.com/goatslacker/alt
reczy 12y ago
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 12y ago
  +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.

rdoherty 12y ago

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.

chadpaulson 12y ago
Valid question. React is actually a UI library, not a framework, and is suited to work with multiple view "backends" including canvas. https://facebook.github.io/react/blog/2013/06/05/why-react.html https://facebook.github.io/react/blog/2013/06/05/why-react.h...
iamsaul 12y ago
react-three [1] is a great example of using React to control something other than 'standard HTML'. [1] https://github.com/Izzimach/react-three https://github.com/Izzimach/react-three
bengotow 12y ago
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-netflix-plans-to-enhance-your-television-experience http://conf.reactjs.com/schedule.html#beyond-the-dom-how-net...

aturek 12y ago

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 12y ago

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

baddox 12y ago
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."

billsimpson 12y ago

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?

aturek 12y ago
If you use a CDN (or use the public CDNs that many of these libraries have) it's not 130 kb, it's a network request + 304
- billsimpson 12y ago
  Yes. The issue for me has been that I bundle my libraries with my app using, for instance, Browserify. So whenever I update the app (which is fairly often), the entire bundle needs to be redownloaded by all clients. I guess the obvious solution is to unbundle the larger libraries that don't get updated frequently.
  - cshenoy 12y ago
    That is absolutely the solution. Don't bundle jQuery and other big libraries into your application code. It can drastically improve performance.
    - billsimpson 12y ago
      In that case, must you create one or more separate bundles to contain your vendor libraries? I suppose there's no way to directly integrate a jQuery library hosted on a public CDN.
caseywebdev 12y ago
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

rtorr 12y ago

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.

jefftchan 12y ago

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

julenx 12y ago

> 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-dynamic-uis.html#what-components-should-have-state http://facebook.github.io/react/docs/interactivity-and-dynam...

jcreamer 12y ago
Great point. Thanks.

jonathancreamer 12y ago

@detaro, here's a version of the image with original and my modified version http://d.pr/i/14Pi0 http://d.pr/i/14Pi0

highpixels 12y ago

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 12y ago
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.

goatslacker 12y ago

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.