Added ability to "#import" graphql files

[Poincare]

The goal is to be able to do this with the webpack loader:

#import "fragment.graphql"
query {
  author {
    ...authorDetails
  }
}

with the following in fragment.graphql:

fragment authorDetails on Author {
  firstName
  lastName
}

This should be equivalent to:

query {
  author {
    ...authorDetails
  }
}
fragment authorDetails on Author {
  firstName
  lastName
}

in a single file.

[stubailo]

I think you probably want to check if this comment is an import - so maybe check for #import. People should still be able to do regular comments in their queries.

[tmeasday]

Would it make sense to put the #import at the point you want the fragment to appear and make it look more like a template inclusion?

[Poincare]

I guess I was thinking of this in terms of "preprocessor directives" which are traditionally at the top. I don't think the choice matters since the definitions can be permuted arbitrarily.

[tmeasday]

I think both ways make sense, but I thought I'd mention it :)

[stubailo]

I think we should support both - here's a good design for directives inline: #25

If someone is interested in tackling it I think it could be a good addition even though I personally prefer the comment approach since it doesn't introduce new GraphQL syntax.

[jole78]

Quick question about this PR. Is this documented in any way?? Just found this issue when trying to use fragments. The documentation on fragments seems out of date.

It seems that options no longer support fragments and the way forward is importing fragments directly in .graphql files. Anyway...recommended way to handle fragments would be nice. Thanks!

[Poincare]

You can handle fragments however you like, this just offers a particular way of doing it. There are some people that want to colocate queries/fragments with the components in their JS/JSX code whereas others want to place them in different files. This PR supports the latter while not preventing the former. I'm not sure how passing around fragments has changed within Apollo Client.

[stubailo]

@jole78 would you mind sending a PR to this page to add information about fragments? http://dev.apollodata.com/react/webpack.html

This #import syntax is currently the only way to do fragments with the Webpack loader.

[jole78]

sure @stubailo I'm glad to help with an example of the #import syntax. Just a question though, are these the 2 recommended ways of including fragments? Meaning:

1. .graphql files (both the query and the fragment/s) and using #import (githunt react seems to use that)
2. using gql tag for both the query and the fragment and using ${fragment} to include in query

There's no way of doing mix and match? Meaning, defining query in .graphql file (webpack loader) and fragment in plain JS. And thus including the fragment via graphql HOC (react at least). For me I find it more clear (and easier) to add the fragment inline with my component that uses the data returned from the query. More that often I find myself doing a list and and listitem approach where the list issues the query and the listitem has the fragment.
I think I might be looking for some guidance here really.

Anyhow, I'll do the PR and again all of you thanks for an awesome library!!

[jole78]

@Poincare no the 2 ways work just fine. Just wondering if you can mix and match them. e.g. query in .graphql file and fragment in plain JS/X using gql tag.
I'm not seeing a way to include the fragment in any options passed to the graphql (react) HOC.

[stubailo]

No you have to pick one or the other right now. Why not simply use the JS format if that's the one you prefer? There is basically no benefit to the webpack approach.