Cache data loss warning on fully normalized query

Client SDKs
, ,
1

Hey :slight_smile:

We have a schema, where part of it is

type User implements Node {
  id: ID!
  fullName: String
  reports: [Report!]!
}

type Report {
  id: ID!
  name: String!
}

union MutationDeleteReportResult = BaseError | MutationDeleteReportSuccess

type MutationDeleteReportSuccess {
  data: User!
}

...
type Mutation {
deleteReport(input: MutationDeleteReportInput!): MutationDeleteReportResult!
}

and a client mutation

mutation DeleteReport($input: MutationDeleteReportInput!) {
  deleteReport(input: $input) {
    ... on MutationDeleteReportSuccess {
      data {
        id
        reports {
          id
          __typename
        }
        __typename
      }
      __typename
    }
    ... on BaseError {
      message
      __typename
    }
    __typename
  }
}

However, when I run the mutation, I get the following warning in the console:

Cache data may be lost when replacing the reports field of a User object.

This could cause additional (usually avoidable) network requests to fetch data that were otherwise cached.

To address this problem (which is not a bug in Apollo Client), define a custom merge function for the User.reports field, so InMemoryCache can safely merge these objects:

  existing: {0: {…}}0: {__ref: 'Report:dd95fe69-e049-4e81-a02f-189e1b19b446'}[[Prototype]]: Object
  incoming: {}[[Prototype]]: Object

This does not make sense to me, because as far as I understand, the query is normalized and the cache should be updated automatically. ID field is queried in the mutation, so the cache should be updated.

The docs says that the default behavior is the incoming overriding the existing, which is the behavior I want and expect. I know I can get rid of the warning by doing

User: {
  fields: {
    reports: {
      merge(_, incoming: any[]) {
        return incoming;
      },
    },
  },
},

but I don’t understand why I would need to?

2

Do you have another query reading name, while the mutation only writes back id?
In the case that the mutation writes back a new entry that didn’t exist before, that would be a new incomplete entry and require another trip to the network before cache data is complete.

3

The GetReports query reads name and ID.

I would expect the cache to be able to then just remove the entries in the array that no longer exist under that user (based on ID comparison), and leave the other entries with any additional fields they might have from other queries.

Do I misunderstand cache normalization?

EDIT:

If a user has two reports, and I delete one, I get the same error but where the warning says something a la

existing: Report:1, Report:2
incoming: Report:1

in case I deleted report 2.

4

I could trace this down to Warn when clobbering non-normalized data in the cache. · apollographql/apollo-client@06a8948 · GitHub, so this behaviour seems to be around for quite some time already.

I don’t really agree with this behaviour for normalized arrays, so I’ll confirm with my colleagues if we can do something about the warning - but in the meantime just know that you are not doing something wrong. Please stick with the merge workaround for the time being.

5

Hey @lenz ,

Thanks for the info :slight_smile:

I think the warning is fine if the array items does not include id or no keyArg has been identified for the type the array holds entities of, but otherwise the warning shouldn’t be shown :slight_smile:

Let me know what your colleagues think, would be nice if we didn’t have to do these custom merge functions for this use case as we have quite a lot of them :slight_smile: