Relay and Redux

[nhagen]

So now that Relay and GraphQL are out in the open, we should start a conversation about how this relates to Redux. Anyone have thoughts on Relay will effect both the core Redux library, and what ecosystem tools will need to be built out to accommodate it?

[CooCooCaCha]

It seems like Redux and Relay are trying to accomplish the same thing, managing your component data. In fact, Redux's @connect decorator seems very similar to Relay's containers. You're basically attaching a data source to your component. In Redux that data source is your reducers and in Relay it's your server and probably a local cache.

[mindjuice]

I think they address two very different parts of "managing your component data".

Redux is simply about transforming your local state via actions and reducers.

Relay is about creating declarative dependency specifications that a hierarchy of components can collect and combine automatically to fetch data from a server without overfetching or underfetching.

The traditional problem that Relay was trying to solve was that a component had to know what data its children required, then had to get it from the local state (assuming it's already been retrieved from the server) and then pass it down to its children via props. If a child component's data needs changed, you needed to change the parent object and possibly the parent's parent, depending on how you'd organized things.

With Relay, the children declare the dependencies and the parent collects and combines them automatically without needing to be aware of what those dependencies are. Then it asks the server for exactly the data it needs.

There's a topic in the reselect project discussing automatic generation of selector dependencies. If you did that, you could probably leverage the data to do something like Relay with Redux, or perhaps feed that data directly to Relay (haven't looked at the Relay code yet, but will soon).

[CooCooCaCha]

Right but Relay has mutations which is also a way of transforming your state. I don't think it's a good idea to have two different systems managing your state. For example, with a todo app, you would have to write an addTodo action for Redux and an addTodo mutation for Relay. This doesn't seem like a good design to me.

I could see Redux being used as a component state manager and a cache layer for Relay. In the blog post they mention investigating offline support in the future for Relay and I wonder if Redux could plug into that and enable time travel with Relay.

[CooCooCaCha]

Actually, we might be part of the way there already. Relay already allows custom network layers:
http://facebook.github.io/relay/docs/guides-network-layer.html#content

If there was a way to handle GraphQL client-side then we could implement a Redux network layer that would intercept those requests and work its magic.

[ide]

Injecting Redux into the Flux Store part of Relay/GraphQL feels directionally right. There are a lot of advantages to using Redux with Relay I can think of:

• Redux devtools work, so you could step back in time through your GraphQL mutations
• Fewer store/dispatcher/actions systems to learn
• Hot reloading
• Can use the Redux store outside of Relay code e.g. for storing client state that you don't want to sync to the server or spend time defining a GraphQL schema for
• The Redux community has put a lot of thought into making Redux extensible -- this would test to see if Redux is extensible enough to support (hypothetical) redux-relay middleware
• Relay/GraphQL applications could benefit from Redux middleware

Pretty exciting stuff after typing it out...

cc @yungsters @josephsavona

[yungsters]

@CooCooCaCha I think integrating at the network layer might be too late into the pipeline.

We are in the early phases (mainly because of the focus on getting Relay open sourced) of exploring ways to expose local data via GraphQL queries and fields. We are definitely inspired by the work on Redux and would like to see how we could fulfill queries for local state from in-memory stores or maybe even native device data sources.

[ForbesLindesay]

One nice thing that Redux support really seamlessly is universal apps, so making this conversion work would make working with universal Relay apps much easier. I view Relay and Redux as two halves of the problem:

• Redux solves the problem of managing local state and mutations (including managing caches of data from the server). However, Redux makes querying server side data relatively imperative (i.e. send the 'GET_DATA' action and wait for the corresponding 'GOT_DATA' action to update the store).
• Relay solves the problem of declaratively managing the active queries you have for server data, fetching that data and then keeping the client's cache up to date in the face of mutations.

There are three really difficult and valuable things that Relay accomplishes:

1. Diff the queries currently executed with the new queries from recently added components in order to query only new data from the server.
2. Optimistically apply updates on the client
3. Model both complex data structures (graph data is a hugely powerful model) and complex queries (which reduces need for round trips).

I can see two barriers to integrating relay & redux:

1. Redux requires all state to be in a single immutable location. Relay appears to store its state in RelayStoreData but in a number of mutable data structures within that. The first step I think would be to pull that out so that this state object could be managed by Redux.
2. Redux uses this.context to seamlessly support universal/isomorphic applications. The same approach could work well in Relay, but it doesn't look like it's currently supported. It looks like components like RelayRootContainer call into the singleton RelayStore and RelayStoreData. getDefaultInstance. I don't know how much work it would be to pull the relay store from this.context or similar.

Note that I do not think that the valuable part of Relay is integration into React. What I wonder is, could way separate out the three highly valuable parts of Relay, and make them function on top of an immutable data store. If we could do that, then integration into Redux would be very simple. We could then experiment with alternative ways of structuring the React portion of the application.

[yungsters]

The same approach could work well in Relay, but it doesn't look like it's currently supported.

This is the (currently unrealized) intent for the RelayStoreData internal module. In theory, we could pass this down through your app via the RootContainer.

[ForbesLindesay]

That would be an excellent first step towards redux integration.

[bsr203]

Hi.. didn't really look into it, but found this repo for an example https://github.com/barbuza/react-redux-relay any progress on relay support

[gaearon]

Also relevant: https://github.com/gyzerok/adrenaline

[fgarcia]

Am Freitag, 18. September 2015 schrieb Dan Abramov :

Also relevant: https://github.com/gyzerok/adrenaline

—
Reply to this email directly or view it on GitHub
#464 (comment).