@connection directive ignored when used in conjunction with keyArgs

I’m back with another caching issue @benjamn, hope you’ll like this one too!

As I understand it, Apollo supports the @connection directive. I understand that keyArgs is better suited for most use-cases, however I’m finding myself in a tricky situation here.

I have an endpoint that’s a relay-style pagination that’s configured to use Apollo Client’s exported relayStylePagination(). This endpoint is called in multiple places in my app, and I would like each place to have its own data instead of sharing the same data from the cache. So my idea was to use a unique @connection directive on each of these queries, so that the result would be stored under different keys in the cache and my lists would be independent.

However, it seems that when I’m applying the @connection directive along with the relayStylePagination(), the directive gets ignored and the data is stored according to the provided keyArgs only.

In the following screenshots, I’m using the same query with different keyArgs configuration on the typePolicy.

The query:

query {
  suggestions({ first: 3 }) @connection(key: "newsfeedSuggestions") {}
}

Here’s what my cache looks like with the keyArgs defined:

Here’s what my cache looks like without keyArgs defined:

Note 1: I realise I can still achieve the desired result using a key args function instead of an array of strings. If this is the intended route, then updating the docs and explicitly stating that keyArgs cannot be used in conjunction with the @connection directive would be nice.

Note 2: my need came from a weird other bug preventing me from having multiple useQuery hooks pointing on the same cache object for paginations. It seems like when I do so, each list is “fighting” the other and tries to write its own result to the cache in a loop, resulting in glitchy and unusable UI.

Intended outcome:

I’m expecting that when using @connection directive along with keyArgs both are used to generate identifiers for my endpoints.

Actual outcome:

@connection directive is ignored.

How to reproduce the issue:

• Use relayStylePagination() to define a field policy. E.g: books: relayStylePagination(['filter'])
• Query this field using @connection directive to set a custom key to store the query result. E.g: books(first: 2) @connection(key: "sideBarBooks") {
• See that it gets stored under ROOT_QUERY.books:{} instead of something like ROOT_QUERY.books:{}:sideBarBooks

Versions

  System:
    OS: macOS 11.5.2
  Binaries:
    Node: 15.14.0 - ~/.nvm/versions/node/v15.14.0/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 7.7.6 - ~/.nvm/versions/node/v15.14.0/bin/npm
  Browsers:
    Chrome: 92.0.4515.159
    Firefox: 88.0
    Safari: 14.1.2
  npmPackages:
    @apollo/client: ^3.4.8 => 3.4.8 
    apollo3-cache-persist: ^0.9.1 => 0.9.1 

[habovh]

@benjamn sorry for the delayed reply. The solution you’ve came up with is really elegant and I believe it fits perfectly this use case, plus many more.

Following your previous comment I was about to suggest that the second approach was the best of the three because it felt like the closest to the current keyArgs-less behaviour. However your solution is orders of magnitude better and far more flexible.

I see #8678 has been merged, is it part of a release already?

[habovh]

@benjamn glad to see that! I may not have a chance to tryout a beta prerelease anytime soon but I’ll definitely be using this once 3.5 gets released.

It has many uses like you said, but this is a pretty advanced feature anyway. By the time you’re looking for this kind of flexibility setting up AC, you’re probably well aware of the inner workings of Apollo Client.

That said, I think this deserves proper documentation under the advanced caching section: it would be a shame to go for a fully customized keyArgs function instead of your simpler and more importantly tested approach if it can yield the desired results.