I’m encountering an issue where I have two documents querying the same field, which is configured to use relayStylePagination with the relevant key args.
One of those documents doesn’t include edges in its selection set:
{
totalCount
}
The other one does:
{
totalCount
edges {
node {
id
}
}
}
If the former completes first, then with the default cache-first policy, Apollo doesn’t perform a network request for the latter. This would make sense if edges had been queried by the former… but they haven’t.
The totalCount field is a deviation of the official Connection interface I’m aware–is this just something that we should account for on our end? Or would it be reasonable to update the upstream function to check if edges has been populated?
Thanks @lenz. I’ve implemented a workaround in the field policy for now but bumped into another issue; doing e.g.
{
edges {
__typename
}
}
will result in edges being written to the cache as [] even if there were results.
I’m beginning to feel like there’s a bit of a documentation gap here. Or that perhaps there should be a “strict” option for relayStylePagination that throws if a query didn’t check the necessary fields.
Yeah, I fear what you are doing is just outside the assumptions that the relayStylePagination was written with.
I feel your pain and we might revisit that in the future, but right now we’re working hard on the Apollo Client 4.0 release, so that is just a comparatively low priority.
The best I can suggest right now is that you copy the pagination over into your codebase and adjust it to your individual needs: