Adjusting the store in order to squash pagination results via Relay's @connection directive.

I am using the Relay convention for pagination as described here. Coming from Relay Modern, there is a directive called @connection. It contains a key which Relay makes use of in order to retrieve all elements of one connection from the store. Apollo Client on the other side does ignore the @connection and stores objects by using keys containing variables like after or count, used to fetch the right amount of data by using a cursor based pagination approach.

The real problem of that comes into play when I am executing a mutation for adding a new edge into the connection. Here the result has to be stored under the correct key in the store via proxy.readQuery(...), which is impossible if you have multiple keys for lists of the same connection.

I think the problem is better understandable with a short example. This is how a proxy store should look like and how it is right now:

Intended outcome:

Project:AAAAAAAAA
  | issues -> ref to $Project:AAAAAAAAA.issues.edges

$Project:AAAAAAAAA.issues.edges
  | edges
    | 0 -> ref to $Project:AAAAAAAAA.issues.edges.0
    | ...

$Project:AAAAAAAAA.issues.edges.0
$Project:AAAAAAAAA.issues.edges.1
$Project:AAAAAAAAA.issues.edges.2
$Project:AAAAAAAAA.issues.edges.pageInfo

Actual outcome:

Project:AAAAAAAAA
  | issues({"first":2,"after":null}) -> ref to $Project:AAAAAAAAA.issues({"first":2,"after":null})
  | issues({"first":1,"after":XYXYXYXYXY}) -> ref to $Project:AAAAAAAAA.issues({"first":1,"after":XYXYXYXYXY})


$Project:AAAAAAAAA.issues({"first":2,"after":null})
  | edges
    | 0 -> ref to $Project:AAAAAAAAA.issues({"first":2,"after":null}).edges.0
    | 1 -> ref to $Project:AAAAAAAAA.issues({"first":2,"after":null}).edges.1
$Project:AAAAAAAAA.issues({"first":1,"after":XYXYXYXYXY})
  | edges
    | 0 -> ref to $Project:AAAAAAAAA.issues({"first":1,"after":XYXYXYXYXY}).edges.0

$Project:AAAAAAAAA.issues({"first":2,"after":null}).edges.0
$Project:AAAAAAAAA.issues({"first":2,"after":null}).edges.1
  | cursor="XYXYXYXYXY"
$Project:AAAAAAAAA.issues({"first":2,"after":null}).edges.pageInfo

$Project:AAAAAAAAA.issues({"first":1,"after":XYXYXYXYXY}).edges.0

How can I tell the Apollo Client store to use a unified key for storing edges of the same connection, ignoring fields like after or cursor used for accessing the field? Is there a way to make use of the @connection information provided in the schema?

[lxwbr]

@helfer just tried it out with #1801 and the store structure seems to be as expected in the intended outcome. Thank you and @shadaj for providing this feature!

[stubailo]

We did want to have this in the original implementation for pagination, but didn’t do it at first because the simpler version has worked fine for a while. I agree that being able to pick a custom store field name is a great way to do this.

We used to call this concept quietArguments and were thinking of an @apolloFetchMore directive: https://github.com/apollographql/apollo-client/pull/350

Perhaps we should bring this back and now may be the time to do it!