apollo-client: Use of GraphQL interfaces causes component to always fetch data from server even if it should already be cached in redux

~~I have a component which utilizes pagination, but it fetches data every time the component mounts, even if the data from the exact same query is already cached in redux. Is this expected?~~

Edit: It is not related to pagination, as originally thought. See below.

This gql query fetches data on the first component mount, and uses local data on subsequent renders:

query {
  notifications {
    id
    type
  }
}

This gql query causes re-fetch every component mount:

query {
  notifications {
    id
    type
    ... on MySpecificType {
      whatever_field_a
      whatever_field_b
    }
  }
}

Seems like it’s probably a problem with apollo client caching implementation for graphql interfaces. I checked the issues and I did not see anything opened about this yet.

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 16 (6 by maintainers)

Most upvoted comments

This should be fixed thanks to #1483. The introspection fragment matcher must be used for union and interface types.

helfer on May 3, 2017

@TSMMark I’m hoping within the next 10 days. @fubhy is currently working on it (see discussion on https://github.com/apollographql/apollo-client/pull/1360)

helfer on Mar 16, 2017

@nnance Yes, that’s definitely possible. There are a few corner-cases with interfaces and unions that the heuristic fragment matching doesn’t quite get right. We’ve decided to just implement a fragment matcher that actually has the knowledge to conclusively decide whether a fragment matches or not. That should solve this and related issues.

helfer on Mar 16, 2017

@helfer It definitely seems like a bug in fragment matching. I am not familiar with any other type of fragments other than “interface”, but it looks like this blog post will help me https://medium.com/the-graphqlhub/graphql-tour-interfaces-and-unions-7dd5be35de0d#.szp76x3ct

I will try to get to this sometime this week.

TSMMark on Dec 13, 2016