interaction with domain state and redux

I have a couple questions about the Apollo Client store implementation

I see in the example that we have one reducer called apollo. What state does this represent? The current query? The thing with ambitious projects like this is I feel that we should be thinking long term. Having all state under one reducer seems like a bad idea and hard to manage going forward. Imagine mapping state to props over a huge reducer whos shape may be nested etc.

you may end up with something like

function mapStateToProps(state) {
   return {
     job: state.apolloReucer.job.title
    foo: state.apolloReducer.foo.bar.baz
  };
}

Is there a way we can represent each query has a slice of our state. Where we somehow generate multiple reducers to manage domain state from different queries?

Sorry if this is naive in approach, just going off the docs at this point!

[stubailo]

The apollo client itself manages both the reducer and mapping state to props - so rather than using redux-react, you would use watchQuery with a custom Apollo container. Check out this article:

https://medium.com/apollo-stack/building-a-graphql-store-from-first-principles-413e19ea65b4

Also, if you have read about Relay, it uses a similar store shape, and it does the same management for you under the hood.

The point is, the store needs to be a normalized cache of result objects, rather than something that keeps the result of each query independently. Right now, it doesn’t bring as much benefit, but once you start dealing with pagination, optimistic UI, data preloading, refetching, etc - you basically need a normalized store to take advantage of GraphQL.

In short, we don’t expect people to be using the apollo part of the redux store directly, but rather with some provided helpers. Here’s a sketch of a React container I wrote for a demo:

const Topic = ({ data, loading, loginToken }) => (
  <div>
    { loading ? 'Loading...' : <TopicLoaded data={data} loginToken={loginToken} /> }
  </div>
);

const TopicWithData = createContainer({
  getQuery: ({ params, loginToken }) => {
    const maybeLoginToken = loginToken ? `(token: "${loginToken}")` : '';

    return `
      {
        root${maybeLoginToken} {
          oneTopic(id: "${params.id}") {
            id
            category_id
            title
            posts {
              pages {
                posts {
                  username
                  score
                  cooked
                }
              }
            }
          }
        }
      }
    `;
  },
}, Topic);

(that’s not the final API, just a sketch)

[abhiaiyer91]

See now this makes more sense. In my mind I envision this playing out something like:

Server data:
ApolloClient -> watchQuery -> container component -> render

Client Data
Store -> ReactRedux -> container component -> render

Then theres a mix client state to server state back to client
Store -> stateFromClient -> watchQuery -> container component -> render

From there you use ActionCreators to as the public API to update Client State / Server State.

Whats the API look for calling a mutation in this world? Are we still using thunk writing functions that under the hood call Apollo methods?