Redux 1.0
github.com
github.com
However, I am very curious about the long-term* future of Redux now that FB's Relay has landed...
(*) long-term in JavaScript-parlance, meaning more than 2 months ;-)
From my point of view flux is pretty much a general architecture pattern. Relay and GraphQL seem much more tied to how facebook works and what there requirements are. It requires that you change your server-side code, which might not be possible for most parties.
One of the not-immediately-obvious problems with the React pattern of passing data in via attrs and actions via callbacks is that the parent component needs to accept all the data/callbacks that all its child components require and its parent in turn needs to do the same. In many projects you wind up needing an additional chunk of data on a child component and that change requiring edits in 8 additional components to pipe around the data.
The Realy/GraphQL (also Falcor from Netflix) idea is that an individual component knows what data it needs and having it describe the data it needs and those requirements being aggregated into a hiearchical query over the graph of data present on the server. Structuring your data requirements this way solves both client side (the problem I mention above) and server side problems (supporting multiple client apps with similar but not the same data requirements, only having to write the code to expose a table as part of a query instead of having to shape it to various endpoints).
At least that's the idea. I find Relay as released to be unpleasant just like I found Flux as originally released to be unpleasant. Now that the code is out there expect a million Relay re-implementations before a rough consensus winner emerges. I expect the winner to look something like a combination of react-resolver with some redux middleware.