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

Import directive within GraphQL files #1477

Closed
hmaurer opened this issue Jun 1, 2018 · 5 comments
Closed

Import directive within GraphQL files #1477

hmaurer opened this issue Jun 1, 2018 · 5 comments

Comments

@hmaurer
Copy link

hmaurer commented Jun 1, 2018

Hi!

I am opening this issue to ask whether the addition of an import directive in GraphQL (.graphql) files has been considered and/or is currently being worked on. To be more specific, I am referring to the #import syntax used by webpack-graphql-loader, like so:

#import "./fragments.graphql"
 
query {
  ...a
  ...b
}

The implementation by webpack-graphql-loader is a little dirty but pragmatic (they essentially do a search-and-replace for "#import" directives).

Since this is also the recommended approach in Apollo's documentation, I think that it would be a useful addition to Parcel.

I did not open this issue as a feature request because if this is not something currently being worked on I would be happy to contribute myself.

@DeMoorJasper
Copy link
Member

Haven't seen anyone working on it.
Would be nice if you could implement it :)

@agonbina
Copy link

@hmaurer did you ever get around implementing this feature? I am not even sure how else do you share fragments between queries/mutations unless you are able to import them in the .graphql somehow.

@hmaurer
Copy link
Author

hmaurer commented Jul 12, 2018

HI @agonbina ! No, sorry :( I moved away from .graphql files to defining the queries/fragments in my .js files and so I didn't have a pressing need for this feature. I do agree it seems pretty much essential when working with .graphql files though but I don't have the time to implement it right now.

@agonbina
Copy link

There is a workaround to get this to work and still keep your fragments in .graphql files. Here is an example with react-apollo

import { concatAST } from 'graphql'
import { graphql } from 'react-apollo'

import customerFragment from './customer.fragment.graphql'
import customerQuery from './customer.graphql'

export const withCustomer = graphql(concatAST([customerFragment, customerQuery]), {
  name: 'customerQuery'
})

It is more cumbersome but on the other hand you don't need to use the #import directive which is not party of the graphql spec anyway. And the visual studio code extension for GraphQL is able to find and understand the fragments that you use in your queries/mutations.

@nabiltntn
Copy link

I created PR #1817 to add this feature

devongovett pushed a commit that referenced this issue Oct 15, 2018
An alternative to #1817 that doesn't rely on using `graphql-tag/loader`, which is a Webpack loader.

#### What this does:
1. Recursively traverse the GraphQL files.
2. Collect all the imports into a map.
3. Concatenate them.
4. Parse the result into an AST.

#### What this doesn't do:

This PR (as of time of writing) does not have feature parity with `graphql-tag/loader`, meaning that:
* It does not de-duplicate fragments that have the same name. _This is a behavior that I personally disapprove of since it can lead to surprising results instead of throwing an error if a user accidentally (however unlikely) reuses an already defined fragment name._
* It does not collect multiple defined queries/mutations and make them individually require-able from a JavaScript parent.


If the above behaviours are desired then I can implement them.
devongovett pushed a commit that referenced this issue Oct 15, 2018
An alternative to #1817 that doesn't rely on using `graphql-tag/loader`, which is a Webpack loader.

#### What this does:
1. Recursively traverse the GraphQL files.
2. Collect all the imports into a map.
3. Concatenate them.
4. Parse the result into an AST.

#### What this doesn't do:

This PR (as of time of writing) does not have feature parity with `graphql-tag/loader`, meaning that:
* It does not de-duplicate fragments that have the same name. _This is a behavior that I personally disapprove of since it can lead to surprising results instead of throwing an error if a user accidentally (however unlikely) reuses an already defined fragment name._
* It does not collect multiple defined queries/mutations and make them individually require-able from a JavaScript parent.


If the above behaviours are desired then I can implement them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants