What the Flux?(jonathancreamer.com)
jonathancreamer.com
What the Flux?
http://jonathancreamer.com/what-the-flux/
55 comments
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.
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.
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.
I agree. A version of the diagram that showed the official name next to the description would be a great self-contained small reference.
I'll see what I can do. :)
Great! Glad it helped.
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
[2] https://github.com/yahoo/fetchr
- 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
[2] https://github.com/yahoo/fetchr
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.
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!!
> 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
[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
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
[1]: https://github.com/spoike/refluxjs
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
[1] http://facebook.github.io/react/html-jsx.html
Interesting. Would make it much easier for me alleviate concerns and be able to use React for projects. Thanks!
I think it would be quite difficult to build a meaningful app with React and not use something Flux-like. My own experience went like this:
I started off by putting all state in Elements, because that is what the React docs encourage. Eventually, I needed to persist the state and/or access it outside the element (because it is actual fucking state used for business logic). At that point in time, I tried passing callbacks into the Elements per the docs. Of course, this is ridiculously cumbersome when the element is nested 5 or 6 levels below the entry point. Then, I tried hooking up Backbone models and sucking data out of those but two way data binding turned my code into spaghetti. Enter flux! This was perhaps a week or two of pain we can spare others.
I started off by putting all state in Elements, because that is what the React docs encourage. Eventually, I needed to persist the state and/or access it outside the element (because it is actual fucking state used for business logic). At that point in time, I tried passing callbacks into the Elements per the docs. Of course, this is ridiculously cumbersome when the element is nested 5 or 6 levels below the entry point. Then, I tried hooking up Backbone models and sucking data out of those but two way data binding turned my code into spaghetti. Enter flux! This was perhaps a week or two of pain we can spare others.
[deleted]
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.
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-net...
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.h...
react-three [1] is a great example of using React to control something other than 'standard HTML'.
[1] https://github.com/Izzimach/react-three
[1] https://github.com/Izzimach/react-three
> 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...
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...
Great point. Thanks.
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.
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/ [2] https://news.ycombinator.com/item?id=8923053
[1] http://martyjs.org/ [2] https://news.ycombinator.com/item?id=8923053
+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.
I suggest having a look at Alt. https://github.com/goatslacker/alt
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.
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?
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?
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.
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?
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?
I've used github/fetch [1] which is a polyfill for the upcoming fetch standard [2]. If you ever want to go beyond this its one of state sources in marty.js [3]
[1] https://github.com/github/fetch [2] https://fetch.spec.whatwg.org/ [3] http://martyjs.org/guides/state-sources/http.html
[1] https://github.com/github/fetch [2] https://fetch.spec.whatwg.org/ [3] http://martyjs.org/guides/state-sources/http.html
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
superagent: https://github.com/visionmedia/superagent
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
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
Have you tried Zepto[1]? It's ~9kb gzipped, and is compatible with a lot of jQuery's API. I've found that for a lot of the stuff I used jQuery for, it's mostly a drop-in replacement.
[1]: http://zeptojs.com/
[1]: http://zeptojs.com/
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
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.
That is absolutely the solution. Don't bundle jQuery and other big libraries into your application code. It can drastically improve performance.
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.
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?
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?
" 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.
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.
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.
I built a few small things and these examples really helped... https://github.com/facebook/flux/tree/master/examples/
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.
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.
Awesome post man. People often overcomplicate simple concepts wayyyy too much.
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.
Thanks! I had fun writing it and learning flux. :)
I only just got my head around angular, and now flux + react have come along and wrecked the party.
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...
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.
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.
lol, I hear ya
Topical and recent: https://www.nilas.com/blog/splitting-the-atom (some more talk about people using Flux)
MVC with an event bus (I mean, um, "Flux") is about as far from "computer science" as you can get. Software engineering, maybe.
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."
@detaro, here's a version of the image with original and my modified version
http://d.pr/i/14Pi0
http://d.pr/i/14Pi0
This reminds me of looking at JSF