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

Feature request: Allow to import specific fragment from .graphql file with many fragments #102

Open
chris-verclytte opened this issue Jun 20, 2017 · 7 comments

Comments

@chris-verclytte
Copy link

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. #
@stephen
Copy link

stephen commented Jul 19, 2017

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?

@TinkGu
Copy link

TinkGu commented Sep 6, 2017

+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'

@jnwng
Copy link
Contributor

jnwng commented Dec 7, 2017

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!

@klemenoslaj
Copy link

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.

@jnwng
Copy link
Contributor

jnwng commented Feb 4, 2019

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.

@klemenoslaj
Copy link

@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?

@dobesv
Copy link
Contributor

dobesv commented May 3, 2019

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

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

6 participants