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

@include not working on fragments #74

Closed
fruitcoder opened this issue Mar 28, 2017 · 2 comments
Closed

@include not working on fragments #74

fruitcoder opened this issue Mar 28, 2017 · 2 comments

Comments

@fruitcoder
Copy link

I have the following query

query BookmarkListAllItems($id: ID!, $includeInfo: Boolean!, $batchCount: Int = 12, $cursor: String) {
  viewer {
    bookmarks(id: $id) {
      items(first: $batchCount, after: $cursor) {
        pageInfo {
          hasNextPage
        }
        edges {
          cursor
          node {
            id
            ...GQLBasicInfo @include(if: $includeInfo)
            ...GQLOtherInfo @include(if: $includeInfo)
          }
        }
      }
    }
  }
}

fragment GQLBasicInfo on SomeInterface {
  title
  ...
}

fragment GQLOtherInfo on SomeInterface {
  description
  ...
}

I use this query to get either just ids or a bunch of other info based on the includeInfo variable. When it's set to true everything works fine, but setting it to false leads to an error from the Apollo framework, which looks like this:

▿ some : GraphQLResultError
    ▿ path : 7 elements
      - 0 : "viewer"
      - 1 : "bookmarks"
      - 2 : "items"
      - 3 : "edges"
      - 4 : "0"
      - 5 : "node"
      - 6 : "title"
    - underlying : Apollo.JSONDecodingError.missingValue

So it seems that Apollo is expecting the title field to be in the response during parsing although it shouldn't care about it.

@martijnwalraven
Copy link
Contributor

I just released Apollo iOS 0.7.0-alpha.1, which uses the updated codegen and should support @skip/@include. There have been quite a few changes to the codegen, so there might be slight differences in the generated code (especially for type conditions). That's one of the reasons I've labeled it alpha for now. Would be great if people could try it out and provide feedback!

@martijnwalraven
Copy link
Contributor

Closing this so we can have a single issue for discussion of @skip/@include support: #74

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants