Apollo-client: Nested fragment results arent't merged into a query result

Created on 23 Mar 2017  ·  9Comments  ·  Source: apollographql/apollo-client

When a fragment selects nested fields and the original query also selects fields on that type, the fields from the fragment are left out and only the ones from the query are in the result.

Intended outcome:

The results from the nested fields of the fragment should be merged into the complete result.

Actual outcome:

The nested fields are left out.

How to reproduce the issue:

Here's a query that can be run in Githunts' GraphiQL. Notice that login as well as avatar_url is available in the result.

When the same query is run with apollo-client, only avatar_url is available in the result.

Here's a node script that shows the issue:

require('isomorphic-fetch');
const {default: ApolloClient, createNetworkInterface} = require('apollo-client');
const gql = require('graphql-tag').default;

const client = new ApolloClient({
  networkInterface: createNetworkInterface({uri: 'http://www.githunt.com/graphql'})
});

const query = gql`
fragment RepositoryData on Repository {
  owner {
    login
  }
}

{
  feed(type: NEW, limit: 5) {
    repository {
      ...RepositoryData
      name
      owner {
        avatar_url
      }
    }
  }
}
`;

const promise = client.query({query}).then(({data}) => {
  console.log(JSON.stringify(data));
}, e => {
  console.error(res);
});

🐞 bug

Most helpful comment

if you change

repository {
  ...RepositoryData
  name
  owner {
    avatar_url
  }
}

to read like this:

repository {
  name
  owner {
    avatar_url
  }
  ...RepositoryData
}

it works. This also works for as many fragments in any order, so it seems for now it's best to always put them last.

All 9 comments

@amannn any chance that the Repository type is a union or an interface? If so, we're about to fix this in #1483

If not, a reproduction using https://github.com/apollographql/react-apollo-error-template would be of great help!

Thanks for the quick reply! Repository is a regular type. Also in my app code I'm encountering this bug with a regular type that is not related to a union or an interface.

Here's a fork of react-apollo-error-template that shows the error: https://github.com/amannn/react-apollo-error-template. In this case the name of the organization isn't included in the data that is passed to the view.

As I tried to show with my node example, this error shouldn't be related to react-apollo but rather to apollo-client.

Thanks for your help!

@amannn sorry this dropped off my radar. Are you still facing this issue?

@helfer No worries, I was able to work around it so far.

I just updated my node script to use [email protected], [email protected] and [email protected].

I've also made it a bit clearer which fields are available and which aren't:

require('isomorphic-fetch');
const {default: ApolloClient, createNetworkInterface} = require('apollo-client');
const gql = require('graphql-tag').default;

const client = new ApolloClient({
  networkInterface: createNetworkInterface({uri: 'http://www.githunt.com/graphql'})
});

const query = gql`
fragment RepositoryData on Repository {
  owner {
    login
  }
}

{
  feed(type: NEW, limit: 5) {
    repository {
      ...RepositoryData
      name
      owner {
        avatar_url
      }
    }
  }
}
`;

const promise = client.query({query}).then(({data}) => {
  const {owner} = data.feed[0].repository;
  console.log(owner.avatar_url); // https://avatars…
  console.log(owner.login); // undefined
}, e => {
  console.error(e);
});

It seems like the problem is still there. If you remove the owner override of the query, the login is printed to the console.

As mentioned in the initial comment, this query runs perfectly fine in GraphiQL, so I guess this is a bug of Apollo client.

Ok, thanks, I'll look into it before the end of the week!

if you change

repository {
  ...RepositoryData
  name
  owner {
    avatar_url
  }
}

to read like this:

repository {
  name
  owner {
    avatar_url
  }
  ...RepositoryData
}

it works. This also works for as many fragments in any order, so it seems for now it's best to always put them last.

Thanks @ksmth, that's a pretty simple workaround then. I'll still try to get it fixed, but I might make it lower priority for now.

I've found that this issue is related to graphql-anywhere, and in fact, it has already been reported: apollographql/graphql-anywhere#41

Note that this issue is now fixed as of graphql-anywhere 3.1.0

Was this page helpful?
0 / 5 - 0 ratings