Wow. Branch universal with relay is awesome! I think you build future Rails on nodejs.

[nodkz]

On the past week I decided to choose Relay as state manipulator on the client side. Before it was Redux as well-advertised. But I spent some time to investigate GraphQL and Relay, and understood that is this technology with which I want and would work. Relay like ruby-way. Redux like php-way.

Redux reached the limit of its development. Nothing new we will not see.
Relay right now in active development. I watch their repo, and see how they grow.

I recommend you to move branch universal to another repo, and give it name react-universal2or relay-universal or something else. It will be better, than kill awesome Redux-React kit, when you will switched to new version, leave it as is. Just add in README.md, that you work under a another kit - Relay-React.

PS. Yesterday I tried to switch project build on your kit to Babel 6 and fails. Today I found that you already done it. You are incredibly cool dude. I am your fan!!!

[cdebotton]

Just an update on this, as much as I love Relay, for web apps, I have had a lot of issues with managing local state data on top of the network data from Relay. I tried mixing Redux and Relay with some not so fun results, so I think my intent is to make a GraphQL middleware for Redux that will be able to query and mutate GraphQL data much like Relay, though it will not be as comprehensive as Relay. I'll start that up as a separate package hopefully in the near future.

[bnoguchi]

@cdebotton Can you elaborate on some of the "not so fun results" you encountered?

[wmertens]

FYI https://github.com/denvned/isomorphic-relay isomorphic relay exists now…

I would love Relay+Redux. Relay handles getting the currently required slice of server data from the server in a robust way, and Redux handles local app state in a robust way.

I haven't tried merging the two yet, but my reasoning is:

They both provide data as props to the components, and the props are mixed together, so as long as there is no interaction, it should work as advertised.

However, there is interaction (server state implying client state changes, client changes resulting in mutations), and that will require a bridge between Relay and Redux. @cdebotton is that the source of your not so fun results?

[cdebotton]

@wmertens, @bnoguchi,

Note, I haven't used Relay in two months or so I'm uncertain of its current API.

The issue I had with using Redux and Relay concurrently was that the two were effectively created to solve similar problems, totally differently. Redux manages a global state with no assumption as to how data enters its stores, whereas Relay manages a global store where data is explicitly expected to come through network requests. Using the two in conjunction with each other felt sloppy and half hearted, we have two application states that are totally unaware of the one another.

I believe the example where I dropped trying to work with the two was using Redux to manage local state for forms, while Relay managed it's connection to a network source. Passing the data from Relay into Redux was simple enough, we have a Relay container that passes its props into a Redux connector. We use redux to manage things like storing data, validation information, etc. The problem is that we have the exact same data duplicated in memory.

Similarly, I tried using Redux to store local session data and Relay for all network data, passing data between the two was difficult to do cleanly.

I really love the colocation of network requests to components, and the reduction of network calls, that Relay provides, but storing global application data requires a different data store, and using Redux typically either ended up with duplication of data, or the need to keep track of what data exists in which store.

I am aware that people have figured out how to render Relay isomorphically, though, correct me if I'm wrong, it was a bit of a hack, wasn't it?

I think my goal for the first quarter of 2016 is going to be to build network micro-library on top of Redux that sends network requests by way of GraphQL and folds the data into the store through a specialized network reducer. This would ideally allow AJAX calls to be made at the component level rather than depending on react router, as it's often done currently, and mimic some of the conveniences of Relay without diving too far into its caching mechanisms and model of managing data connections.

[wmertens]

So we have Relay, which allows you to specify a slice of server state and get it efficiently, as well as allowing you to request server side effects via mutations.

Then we have Redux, which allows you to manage local state and allows you to request any side effects via dispatch.

So the missing part in Relay is managing local state, and Redux is so abstract that server state management is an implementation detail. Redux is also a tiny library.

The problem with having the two interact is that actions need to be able to read the server state, right?

Conceptually, I think it would be nice to add Redux to Relay, using a wrapper around Relay. Local state could be integrated into the fragment specification, and mutations are performed by actions when needed.

To allow reading from the server state for actions, an action could request a fragment and hopefully that gets served from cache if available (not sure if Relay does much caching). Perhaps the action fragments could be merged with the component that will use it.

The hardest part would probably be extracting the local state requirements from the fragment and converting them to state slices. Perhaps easier to simply specify that as before in connect.

[wmertens]

See also facebook/relay#114