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.
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.
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.
" 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.
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!!
[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.
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.
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'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.
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 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.
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.
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."
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?
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.
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.
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 ;)
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.
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.
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]
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.
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.
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].
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?
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.
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.
55 comments
[ 6.2 ms ] story [ 134 ms ] threadFlux 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.
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?
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.
[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
[1]: https://github.com/spoike/refluxjs
[1] http://facebook.github.io/react/html-jsx.html
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.
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.
[1] http://martyjs.org/ [2] https://news.ycombinator.com/item?id=8923053
[1] https://github.com/Izzimach/react-three
http://conf.reactjs.com/schedule.html#beyond-the-dom-how-net...
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?
superagent: https://github.com/visionmedia/superagent
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
[1]: http://zeptojs.com/
[1] https://github.com/github/fetch [2] https://fetch.spec.whatwg.org/ [3] http://martyjs.org/guides/state-sources/http.html
- 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
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://d.pr/i/14Pi0
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?
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.