5

It's possible to pass a query, but apparently not a fragment:

server.use('/graphiql', graphiqlExpress({
    endpointURL: '/graphql',
    query: `# Welcome to GraphiQL

query PostsForAuthor {
  author(id: 1) {
    firstName
    posts {
      title
      votes
    }
  }
}`}));


Update 10/12/2017 It is possible to send fragments along with a query using Apollo's client:

http://dev.apollodata.com/core/fragments.html

This is not a solution to the original question, however; I would like to pass fragments to a graphiql server instance at startup.

Jeff Lowery
  • 2,492
  • 2
  • 32
  • 40

2 Answers2

1

by startup do you mean from the server? if so I don't believe that's how fragments are used. my understanding is as follows:

  1. on the server you provide Types (like User)
  2. on the client you query those Types using queries and fragments

for instance, if you provide type User on the server, on the client graphQL you can use fragments to query that type:

graphQL (client)

fragment authorData on AuthorType{
  firstName
  posts {
    title
    votes
  }
}

query PostsForAuthor {
  author(id: 1) {
    ...authorData
  }
}
Yashwardhan Pauranik
  • 5,370
  • 5
  • 42
  • 65
galki
  • 8,149
  • 7
  • 50
  • 62
  • If you look at the OP, you'll see that there is a query: option passed to the server. I can't seem to find this in the current documentation for apollo-server, however. My question was: if query, why not a fragment? The two are interrelated, so it seems logical to allow both. – Jeff Lowery Feb 12 '18 at 19:58
  • i see what you mean. so yes in the server you can specify query and mutation but not fragments because: in the server you specify what queries the client can use, and in the client you are free to write those queries using 2 formats: query and fragment. maybe you say, "id like to reuse this particular query and dont want to rewrite it each time so ill make it into a fragment and use that" - the server doesnt care if its a query or fragment as it already did its job of specifying what can be queried (not how). – galki Feb 13 '18 at 00:09
  • Queries aren't written in stone, either. A fragment doesn't detract from the documentation of possible queries. One is not obligated to use a fragment, just because it exists. – Jeff Lowery Feb 14 '18 at 01:34
  • when you say "fragments exist" - do you mean on the server? – galki Feb 14 '18 at 01:40
  • I mean in the initial query string that is passed to graphiql (not graphql), and shows up in the left pane. – Jeff Lowery Feb 15 '18 at 19:51
  • and the example i suggested is not what you're talking about / doesn't work? ... let me update it to match your fields – galki Feb 16 '18 at 03:06
  • btw theres no concept of "pre-population" in graphql client - what you query for is what you get – galki Feb 16 '18 at 03:15
  • "btw theres no concept of "pre-population" in graphql client" who's talking about that? Not me. – Jeff Lowery Feb 17 '18 at 04:49
0

As you noticed (and as detailed here) GraphiQL takes a query argument:

query: an optional GraphQL string to use as the initial displayed query, if undefined is provided, the stored query or defaultQuery will be used.

If putting a fragment in as the value for that argument doesn't work, then I don't believe there is any way to start with a fragment ... but really why would you even want to? A fragment by itself isn't executable, and the whole idea is to start GraphiQL with a (executable) query.

If all you want is to be able to copy/paste in some text that you use frequently in your queries, a bookmarklet might be a better idea.

machineghost
  • 33,529
  • 30
  • 159
  • 234
  • 2
    The thought was to pre-populate GraphQL with fragments to be used in later queries, no so much to execute immediately. – Jeff Lowery Jan 01 '18 at 22:32