What the Flux?

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.

For me, the part of Flux that&#x27;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:<p>- how do you resolve server &#x2F; client data conflicts?<p>- how do stores work with a RESTful API?<p>- how do you handle network failures, retries, etc?<p>At Quizlet, we designed a hybrid solution [1] with &quot;syncers&quot; that act as the gateway for network I&#x2F;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.<p>I&#x27;m curious to see how other people are approaching this problem.<p>[1] <a href="https://news.ycombinator.com/item?id=8954733" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8954733</a><p>[2] <a href="https://github.com/yahoo/fetchr" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;yahoo&#x2F;fetchr</a>

I started using React around 0.4 and I would recommend skipping Flux at first (or entirely) and just learning React. I&#x27;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.

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&#x27;t need any HTML generation or templates, I just need a solid events and high-level layouts.

&gt; So, every component in React has state.<p>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&#x27;s worth noting that having stateful components is not a requirement. Moreover, the lesser state in a component, the better [1].<p>[1] <a href="http://facebook.github.io/react/docs/interactivity-and-dynamic-uis.html#what-components-should-have-state" rel="nofollow">http:&#x2F;&#x2F;facebook.github.io&#x2F;react&#x2F;docs&#x2F;interactivity-and-dynam...</a>

I&#x27;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.

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&#x27;s flux implementation, and have no regrets.

I&#x27;ve never quite understood Flux, partly due to all the cruft &amp; boilerplate involved around Actions &amp; Action Creators.<p>I&#x27;ve found a Command Bus pattern (a la CQRS) works much nicer, and cleaner.<p>1. Something happens in View (e.g. todo item is checked) 2. View passes a &quot;CompleteTodoItemCommand&quot; 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<p>That said, I&#x27;ve only built a few smaller projects in React, so perhaps I&#x27;m missing something important which Flux solves and I&#x27;m missing?

This is a bit off topic, but whenever I&#x27;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)?<p>I keep backing off, and sticking with jQuery&#x2F;Backbone. One solution would be using a lightweight AJAX library in place of jQuery, but I haven&#x27;t found one that is widely used, well maintained, and recommended. Can anyone recommend one?<p>Or in 2015 should an extra 130 kB be considered a non-issue?

<i>When I look at the docs and blog posts about Flux, and React, my brain goes..</i><p>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?

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.<p>After you&#x27;ve got everything set up it&#x27;s smooth sailing though and you live with no regrets. Getting up that first hill though is tough.<p>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.

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

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

Topical and recent: <a href="https://www.nilas.com/blog/splitting-the-atom" rel="nofollow">https:&#x2F;&#x2F;www.nilas.com&#x2F;blog&#x2F;splitting-the-atom</a> (some more talk about people using Flux)

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

@detaro, here&#x27;s a version of the image with original and my modified version<p><a href="http://d.pr/i/14Pi0" rel="nofollow">http:&#x2F;&#x2F;d.pr&#x2F;i&#x2F;14Pi0</a>

This reminds me of looking at JSF