Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Client side schema, resolvers and mutations #274

Closed
timbrandin opened this issue Feb 28, 2017 · 5 comments
Closed

Proposal: Client side schema, resolvers and mutations #274

timbrandin opened this issue Feb 28, 2017 · 5 comments

Comments

@timbrandin
Copy link

timbrandin commented Feb 28, 2017

As mentioned in this thread: apollographql/apollo#75 (comment)

It would be terrific to be able to combine states in a client side graphql implementation.
For example we often have situations where we depend on server side data and client side route information and other client side resources. It is really hard right now to combine them in a well documented and clear way, we see different solutions to this problem every day.

So our suggestion is to be able to have a client side version of graphql with the root query being named "client" instead of "query" and being able to pass down variables created by previous queries to other "query" or "client" implementations in a serial synchronous fashion.

Here's an example of what this could look in a query:

query getCards {
  $cards: cards {
    _id
    name
  }
}
client getWizardStep($route: Route, $location: Location) {
  stepState: calcWizardStep(route: $route, location: $location, $cards) {
    currentCard
    cardCount
  }
}
@stubailo
Copy link
Contributor

I don't think this requires any new graphql stuff right? Could just use an @client directive. We almost implemented this in Apollo but it ended up not being a priority. I'd be happy to work together to make this happen!

@timbrandin
Copy link
Author

timbrandin commented Mar 1, 2017

Ah, so @stubailo you mean like this?

query getCards {
  cards @export(as: "cards") {
    _id
    name
  }
}
query @client getWizardStep($route: Route, $location: Location) {
  stepState: calcWizardStep(route: $route, location: $location, cards: $cards) {
    currentCard
    cardCount
  }
}

And until there's support for the export directive this could work?

import { compose, graphql } from 'react-apollo';
import gql from 'graphql-tag';
import WizardStepComponent from '.';

export default compose(
  grapqhql(gql`
    query getCards {
      cards
        _id
        name
      }
    }
  `),
  grapqhql(gql`
    query @client getWizardStep($route: Route, $location: Location, $cards: Cards) {
      stepState: calcWizardStep(route: $route, location: $location, cards: $cards) {
        currentCard
        cardCount
      }
    }
  `, { options: ({ data: { cards = [] } }) => ({ variables: { cards } }) }),
)(WizardStepComponent);

@stubailo
Copy link
Contributor

Yep! I was actually thinking @client directives on fields in the same query would work as well!

@jnwng was interested in this as well! Here's the original PR that we didn't end up fully merging (that's where the current custom resolvers come from) I'd love to bring that back and make it a real thing! apollographql/apollo-client#809

@leebyron
Copy link
Collaborator

I agree that directives should provide what you need, and no changes are necessary to graphql to do what you're looking to do. In fact you may be able to do this without any directives at all - we use client specific fields using the experimental extend syntax (which graphql.js supports) - we can know what portions of a request are client-only by comparing to the original server-only schema, filtering out anything the server wouldn't know about before sending requests. This has worked out well for us across a few platforms!

@timbrandin
Copy link
Author

Interesting @leebyron, and I'm curious how this could be setup to work with Apollo Client @stubailo, is that maybe a new FR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants