I'm using the same type with and without ID. How to handle this case?

[frederikhors]

I ran into a new problem.

I have:

type Player {
  name: String!
}

type Query {
  players(search: String!): [Player!]
  friends(search: String!): [Player!]
}

In the friends query I do NOT return ids (because I don't need to cache them, these are network-only queries that I need to verify something).

Urql is (correctly) warning me about https://formidable.com/open-source/urql/docs/graphcache/errors/#15-invalid-key error.

I cannot use:

const keys = {
  Player: () => null,
};

because I'm using ids for it elsewhere.

How to handle this case?

[kitten]

I do NOT return ids (because I don't need to cache them, these are network-only queries that I need to verify something)

Still ask for the keyable field, in this case id then, I assume. Any query updates the cache, no matter what they mean for your app, so you'll have to consistently make sure that the same type will be keyable in the same manner.

[frederikhors]

This is not OK. I cannot have multiple Players with the same ID (0).

[frederikhors]

The problem is I do not have IDs on server for friends special query.

[frederikhors]

I think this is an edge case.

[JoviDeCroock]

I mean, doesn't that mean that the backend data model is lacking since that would mean that your Person.friend[0] & Person.friend[1] are the same. In a normalised caching situation you'd prefer having the real ids for these people to ensure data consistency.

If it's really not possible you could consider doing: Player: (data) => data.id || null

[kitten]

Yea, about the above, it seems like the schema is lacking consistency and information here. I'd assume that a Player.friends field could also return ID-less edges. But I'd assume that a Player entity would always need an ID.