I think one thing that's misunderstood about Flux is the store <-> model distinction. Coming from MVC, it's a pretty easy mistake to make, but stores _are_ effectively global state objects: You can access a store's state from any component -- whether that's good practice is doubtful, but it can be done -- and even though you have to call that store's getter in particular, it's not really that different from requesting state from a global object. (As the article hints at, Om makes it even clearer that stores handle global state in the app-state atom.)

All of that is to say that I think Flux-y architectures can help with reasoning about GraphQL's and Relay's data handling, which I think is seconding your opinion, even if it's quibbling a bit with how annoying driving stick (or working in Flux) is. :)

That was my initial thoughts when Relay/GraphQL were announced, but it seems that though Relay is inspired by Flux it is somewhat different. Facebook's most recent post on Relay and GraphQL (http://facebook.github.io/react/blog/2015/02/20/introducing-... - February 20) addresses Relay's relation to Flux at the end and mentions that Facebook actually has apps using Flux and Relay.

Don't forget that Relay means replacing your RESTful routes. If you still want to work with RESTful endpoints, you are going to work with Flux.

I still think Flux will be handy for holding global UI state. Such as visible notifications, sidebar state, etc.

It's easy to speculate that better solutions are possible, but noone has ever actually done it. React (used from a more functional language, like ClojureScript) is the closest system to the world you describe which actually exists.

And no, papers and toy proof-of-concepts don't count. They are extremely interesting, and a necessary first step, but someone needs to build something large and demonstrate effectiveness in the real world before you can make an honest bid for large-scale adoption. As far as I know, no other FRP or functional UI system has done any better than React on that front, yet.

I recommend checking out ClojureScript. The community is really moving in this direction. I find cljs takes React from good to great (I wrote a simple blog post about that here [0]), and up and coming frameworks like reframe [1] are going to make it even better. reframe and even vanilla Reagent/Om/etc are heading in the direction you desire. ClojureScript still has some warts to iron out, but all in all I feel like it's our current best bet for some truly amazing apps in the browser.

[0] -- http://www.mattgreer.org/articles/reagent-rocks/

[1] -- https://github.com/Day8/re-frame

You should write an article or a blog post about that and submit it. I'd upvote it! This thread isn't a good place for your point, which isn't germane to the article.

It's a good point. But don't mistake Flux, GraphQL, cursors, etc. with React.

React is just a great, fast way to interact with the DOM, with much less hoops than usual.

I think the community is still converging toward the proper way to deal with state. First it was passing callbacks, then the Flux pattern, and now there's talk of how GraphQL and Relay fit in.

And speaking of functional approaches, there are those of us who have been inspired by the Clojurescript community (who was in turn inspired by Haskell, as I understand it) and are interested in using cursors (similar to lens) to encapsulate state.

If you're interested in this, perhaps try Elm? I'm not sure about performance, but it does enforce a pure architecture with all state outside the render tree.

It is always an adventure, to discover what will be on the other side of the phrase "Let's be real".

Seeing "Mixins are awesome" is bringing back so many code smells. : (

Can you (or someone else) explain the need for the language to be functional?

My point was that the state of the dropdown is something that perfectly fine to manage directly in the component (nothing else needs to know about it). Things like the selected value would not be something to manage using component state.

I see some similarities with a stateful recursive Rete implementation. I still wouldn't go so far as to say that it is basically a rules engine.

The Rete algorithm (which is the underlying algorithm of most rule engines) trades off memory use for an O(1) execution time (where n==1 and n is the number of rules in the system). You really only gain any benefit once the number of rules grows significantly, and by then memory usage is significant enough that I wouldn't want it running in my browser. If I had a the need for a rule engine in the browser, I would invest most my effort on offloading rule processing to the server instead.

I'm not 100% sure what you mean by rule engines.

I tried to use a FSM for a SPA that was developed with Backbone.js. First it was really useful, but it was really shitty to maintain(expanding etc), though that maybe was fault of implementation. Still it is interesting idea, that I might want to try again.

Can I plug my own book? I’ve made the tutorial available for free just for you http://www.reactbook.org/samples/reacttutorial.html

Quite seriously: http://facebook.github.io/react/docs/getting-started.html

Facebook's documentation is quite good: http://facebook.github.io/react/docs/getting-started.html

They also merge pull requests quickly if you have suggestions or clarifications.

Beside the other links, I found a few react libs very useful. react-router [1] and material-ui [2].

The second one also has an example application that is a great boilerplate (if you like material ui and their work). I've been successfully using it in a couple of small apps [3, 4].

[1] https://github.com/rackt/react-router

[2] https://github.com/callemall/material-ui

[3] http://github.com/ecesena/oscars2015

[4] https://github.com/hasgluten/hasgluten

Other than the docs: https://github.com/ryanflorence/react-training

Sorry, wrong react thread - and I cannot delete this post.

An often overlooked pattern in React is controller-views. When using Flux (or really, with any external-to-the-component data) you should put this Store logic in the nearest parent to the components who use it. This component is the "controller" which gets the data and passes it as properties to the child components (who pass it as required to their children down the hierarchy).

This keeps your child components pure (fast, renders directly from props, uses PureRenderMixin) and keeps data access centralised to the nearest common controller-view component. It's okay to have a parent component that simply collects data to pass directly into a single child within the render() call — the parent fetches data and sets props, the child re-renders only when the props update, and there's a clear separation of responsibility between the two.

That's kind of the point, at least as I understand it. You want to minimize the number virtual nodes that need to be reconciled to actual DOM nodes. If nothing about a parent's props or state has changed, then ideally nothing should have to change about any of its children.

http://facebook.github.io/react/docs/advanced-performance.ht... has the best description of this process I've found so far.

If you use PureRenderMixin, all child components must also be pure. If a pure component wants to change what it renders because of an event, it must change its state, otherwise it won't be re-rendered.

That's only true if you're following the canonical Flux architecture to the letter. There's little difference between having your store trigger setState() on a root component and having your store trigger React.render(<RootComponent/>) with new props.

If anything the docs reiterate (quite a few times) that this is one way, and not a golden bullet. And that flux is just one of the architectures you can use with react.

But you certainly get the award for least imagination.