getStoreKeyName does not honor @connection if field is using defaults for all args (has no args)

[AlexMoutonNoble]

Hi Folks
We have two queries requesting the same Connection style field via two different root queries.
Both of these fields are taking the defaults for the arguments to the field.
In one case we are only interested in a totalCount field on the connection, and on the other we want totalCount and the edges. This produces a warning:

`Cache data may be lost when replacing the clusters field of a TypeCollection object.

To address this problem (which is not a bug in Apollo Client [ed: hi]), either ensure all objects of type TypeClusterConnection have an ID or a custom merge function, or define a custom merge function for the TypeCollection.clusters field, so InMemoryCache can safely merge these objects:
`

It seems to me that a merge function is out of place here since I am not intending for all TypeClusterConnection to be merge. Its only this particular pair of two natural field applications that can be merge. The connection supplied with other arguments would not be mergeable.

Though the keyArgs api is recommended it does not seem applicable for a field where arguments may or may not be provided. (keyArgs would not distinguish these two applications of the connection based on fields)

The recommendation then is to use the @connection directive to specify a hash key per query so I can manually differentiate them. Doing this in this case produces no change.

Looking at the code I see

apollo-client/src/utilities/graphql/storeUtils.ts

Line 140 in b0da267

export function storeKeyNameFromField(

creating an argObj (which will be left unpopulated here)

and

apollo-client/src/utilities/graphql/storeUtils.ts

Line 195 in b0da267

args &&

requiring the arg object be truthy in order to use the connection key

I expect connection key is applied regardless of args.

Without this I am left without a front end means of separating these Connection objects.

Does that seem right?

Thanks
Alex Mouton

[benjamn]

Just letting you know I'm looking into this issue along with some other @connection-related issues: #8659 (comment)

You're right the args && condition doesn't belong there, but I suspect the getStoreKeyName and storeKeyNameFromField functions may be due for a general rewrite/replacement. Sorry for the rough edges!

[benjamn]

@AlexMoutonNoble Please take a look at #8678 when you have a chance! Those changes should allow you to configure

new InMemoryCache({
  typePolicies: {
    Query: {
      fields: {
        yourField: {
          keyArgs: ["@connection", ["key"]],
        },
      },
    },
  },
})

and then use the @connection(key: ...) directive as you normally would in your queries (with different keys, of course).

[hwillson]

These changes are available in @apollo/client@3.5.x - thanks!