Learning Flux sort of seems like learning how to drive stick shift on an '97 Civic while we wait for the new Tesla to arrive - useful, also a bit annoying. A central store architecture does seem a better match to what Relay will look like though.
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. :)
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.
In other words, we can do it in steps.
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.
It seems like the more one uses React, the more they crave the above, so it makes sense to use an environment where all of the above is natural.
There isn't a whole lot of rules engine in JS. Just nools [1] which is huge. I'd love to see a very simple forward chaining rule engine + Immutable + React and see how that would work out.
My guess is that they aren't popular at all because they have the notion of being enterprisey (Drools/Jboss). I'm a big fan of them. They /can/ make life & code very nice and elegant. Maybe somebody writes an JS adapter to clara rules [2].
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 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.
They also merge pull requests quickly if you have suggestions or clarifications.
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
Edit: Turns out my render methods aren't pure. I query stores right render, which causes problems when using this mixin.
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.
http://facebook.github.io/react/docs/advanced-performance.ht... has the best description of this process I've found so far.
But you certainly get the award for least imagination.