Graphql-tag: Feature request: Allow to import specific fragment from .graphql file with many fragments

Created on 20 Jun 2017  路  7Comments  路  Source: apollographql/graphql-tag

In some cases, it would be great to be able to import a specific fragment when defined in a .graphql file alongside with other fragments.
At the moment, only two solutions are available:

  • Write only one fragment per .graphql file which produces a lot of files
  • Declare fragments both in the .graphql file (for the query) and in the components (for props validation and data filtering) which is the solution exposed in GitHunt but imply writing the data requirements in two places and thus is not very maintainable. #
easy help wanted

Most helpful comment

+1. Maybe we can just use ES6 style import in the future

fragment userInfo on UserInfo {
  # some fileds
}

fragment communityUserInfo on UserInfo {
  # some fileds
}

then

#import { userInfo } from './userInfo.gql'

All 7 comments

Not stated above - I beileve it's not possible to do this today because spec-compliant graphql servers will complain about unused fragments.

Alternatively, what if the loader checked for the validity of the graphql queries/fragments and removed unused fragments?

+1. Maybe we can just use ES6 style import in the future

fragment userInfo on UserInfo {
  # some fileds
}

fragment communityUserInfo on UserInfo {
  # some fileds
}

then

#import { userInfo } from './userInfo.gql'

sounds like a fairly reasonable extension of the feature introduced in 2.6.0 to export multiple operations from a graphql document

happily accepting PRs, that PR should help make this easy!

What is the status of this issue? Is the idea abandoned?
Currently we can only produce a huge amount of graphql files which mostly makes no sense unfortunately.

i generally think that this should be subsumed by integrating with efforts like graphql-import which have better support for some of the things mentioned above, rather than building our own version of this stuff in this library.

@jnwng, thanks for a fast reply 馃憤
I absolutely agree with integrating rather than reimplementing, but does that mean integrating it to this library or within end projects?

I've submitted PR #257 to address this, please take a look.

Was this page helpful?
0 / 5 - 0 ratings