What the Flux?
jonathancreamer.com
jonathancreamer.com
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.
- 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.
[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
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.
http://conf.reactjs.com/schedule.html#beyond-the-dom-how-net...
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...
[1] http://martyjs.org/ [2] https://news.ycombinator.com/item?id=8923053
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 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?
[1] https://github.com/github/fetch [2] https://fetch.spec.whatwg.org/ [3] http://martyjs.org/guides/state-sources/http.html
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/
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.
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.
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.