React-apollo: Fragments on interface types missing fields

[mmmdreg]

I'm trying to migrate away from createFragment to the new syntax.

I'm using interface types with some common fields and some unique fields.

When I load a page to display a single item of a certain type, the props are missing the unique fields. If I examine the props in the apollo container, only the common fields are in the data.

However, the network request returns all the correct fields and the apollo redux store entity contains all the correct fields.

It also works fine with the old createFragments syntax.

Does this sound like an apollo bug?

Version

• [email protected]
• [email protected]

[tmeasday]

Are you using filter from graphql-anywhere? It could be a bug in that package. It would be (relatively) simple to write a test that demonstrates that behaviour here: https://github.com/apollostack/graphql-anywhere/blob/master/test/utilities.ts

[mmmdreg]

Quick example typed on my phone:

gql`
query characterById($id: String!) {
  charcter(id: $id) {
    ...DroidDetails
    ...HumanDetails
  }
}
${Droid.fragments.details}
${Human.fragments.details}
`

Droid.fragments = {
  details: gql`
    fragment DroidDetails on Droid {
      episodes { id name year }
    }
  `
}

Human.fragments = {
  details: gql`
    fragment HumanDetails on Human {
      episodes { id name }
    }
  `
}

Now if I load a page using a droid's ID, the network request returns the episodes with id name and year, but the container props only have id and name.

Let me know if you have any questions

[tmeasday]

@mmmdreg does the container filter using the query?

[mmmdreg]

No we're not filtering with or without graphql-anywhere.

The container is like:
graphql(query, {
props: ({ownProps, data}) => {
// data is already missing the fields.
return {
data
}
}

Just checked versions and it seems it only worked back at [email protected], so something in the fragment changes coming through in recent versions.

[tmeasday]

Hmm, OK, so this sounds like an apollo-client issue then. I think you may just be running into this problem: https://github.com/apollostack/apollo-client/issues/771 because AC cannot tell if the interface should apply to your concrete type.

[vovacodes]

@tmeasday I also had this issue, I tried to debug it and looks like the issue is here:
https://github.com/apollostack/graphql-anywhere/blob/master/src/index.ts#L254

In the example from @mmmdreg the thing is that every object from a store is being matched against several fragment definitions and the output object is the result of this merge call:
https://github.com/apollostack/graphql-anywhere/blob/master/src/index.ts#L162

But merge function doesn't work correctly, namely, once resolved, human.episodes field will never be overridden by or merged with droid.episodes because of the line I mentioned first. Please let me know if you'd like a better explanation, but the issue is actually not that straightforward to explain if not seeing what happens in debug mode.

In the meanwhile, I will try to contribute the failing test to graphql-everywhere

[jbaxleyiii]

Issue with GA / AC. (and I think fixed!)