Relay: GraphQLRange cannot find a segment that has the cursor X

[danmooney]

I'm passing a cursor in a URL for windowed (multi-page) pagination purposes. When the paginated list is fetched from GraphQL after a hard refresh, the correct paginated list data is observed in the response from the network call. However, it appears that _cursorToIndexMap (or any cursor data for that matter) is empty on initial page load as Relay tries to retrieve range info for the query, and Relay raises a warning: GraphQLRange cannot find a segment that has the cursor: X, where X represents the cursor passed in the URL. Relay then discards all of my edge data before passing anything off to its Relay containers. Is there any way to proceed with providing the data it fetches from GraphQL? How can this warning be reconciled? Is Relay unable to start from the middle of a paginated list of data?

[Longsight]

Hi @danmooney,

I'm actually working against the same problem at present so have all the relevant links open in front of me - the short version is that Relay doesn't currently support windowed pagination from arbitrary start points, as is likely happening during a hard refresh (especially if you're building your cursors yourself in that case). Instead, it's designed to support fast reconciliation of infinite scroll problems, using opaque cursors provided in each response to construct each consequent query. These cursors don't support mocking, even if they're otherwise built to a known spec and look identical to cursors fetched under normal circumstances.

Note that this is a current limitation in Relay and not in GraphQL, which is why you'll see the correct list data coming back from the server - Relay just doesn't yet understand how to intelligently insert the new connection data into the store without already having a cached cursor to work with. Discussion of the pagination problem and the history behind it can be found at issue #540, along with some easy workarounds until windowed pagination is fully supported as a connection method.

[josephsavona]

@Longsight Great answer, that sums it up nicely.

I'm actually working on a new way of representing connections (aka ranges) and will keep this use case in mind.

[Longsight]

I'm particularly interested in this one - we're working on getting an RN + Relay app into the wild, and our use case would benefit specifically from being able to combine infinite scroll and arbitrary windowed pagination, as well as deferred queries and a few other goodies. At the moment I'm using a couple of workarounds to achieve acceptable performance, but I've dug through GraphQLRange at length and am keeping a close eye on where it goes.

[gre]

Can't wait to have this fixed. I also have an app where "starting from cursor X" is a really important use-case.. and using a custom "after" like filter field is not beautiful.

[wincent]

Closing this because no further work is being done on the Relay Classic connections API. All future work will take place against the Relay Modern API, which is an entirely new implementation and doesn't use GraphQLRange at all. Please open new issues for any issues related to pagination with the new APIs.