Idea: Factor out a graphQLSelector to be used independently

@gaearon has been talking a ton about a new-ish concept for Redux called “selectors” - basically the idea that your Redux store shape can be an implementation detail of the store logic, and then you use custom functions as the actual public API to get data out.

readQueryFromStore is basically exactly this for Apollo - it’s a selector that takes a GraphQL query and generates that result from the normalized store format. Now that there’s a name for this concept and some great recommendations for how to use selectors, we should make sure that taking this approach with Apollo Client makes sense. We might also want to rename our internal functions to map onto this concept so that people familiar with Redux might feel more at home.

This can be as simple as exporting the selector properly, and teaching people how to use that in vanilla Redux connect or their reducers to do custom GraphQL stuff.

@abhiaiyer91 want to take a stab at the design? Since the ApolloClient takes some options that affect how denormalization/selecting might work, we might want this to be a function on client, something like:

// Question: where to get `client` from? It lives on context, but we can't access that here...
mapStateToProps: (state) => ({
  graphQLData: client.selector(state.apollo.data, {
    query: gql`...`,
    variables: {},
  })
})

With a little bit of cleverness, this API could be extended to work for fetching any appropriately normalized Redux data with a GraphQL query.

[abhiaiyer91]

I have a question about this one. Why does this have to be a method off the client itself, this should be a stateless function that handles the computation no? Ideally a selector that given inputs outputs normalized data?

[stubailo]

Well guys I wanted to have some fun, so I made a ton of progress in this direction:

https://github.com/stubailo/graphql-anywhere

It’s a totally standalone library that factors out all of apollo’s query execution functionality, and even removes the need for a custom store format.

Hope to refactor AC to use this soon, and perhaps make a complementary normalization library - like normalizr, but one that takes advantage of GraphQL’s structure.