Regularity of Relay opaque edge cursors in two executions of a query

[nimmolo]

Say I have an ordinary "blog entries by date" that is queried using Relay-style cursor based pagination, and i have a UI where users can scroll through the blog entries in a virtual list. Each blog entry has an opaque string cursor.

Since there are a lot of blog entries, I'd like to make an interface so users can "jump to a date" and start scrolling at a specific date -- and be able to scroll both backwards and forwards from that date.

To implement this, I'm thinking i'd make an extra query to find the cursor of the first entry on or after that date, and then refetch the main blog query starting at that cursor. That way, the main query remains a query for all blog posts, and I've just moved the window to the cursor the user wants, and they can scroll forward and backward by date.

I know the cursor is not predictable, but my question is, does the second query generate the same cursor for the same blog entry that the original query (all posts) would generate for the identical blog entry?

Or are cursors for queries unique to the query, so that Query 1's cursor for post_ID 2021 is different from Query 2's cursor for the same post_ID 2021?

(This seems to be really a question about how opaque cursors are generated in the Relay spec, but i couldn't find the answer in the spec. Maybe the implementation differs in different environments, and this is the right place for the question. Hopefully this is a question someone can answer off the top of their head.)

[rmosolgo]

Hi! No, there's no guarantee that an object will have the same cursor in different queries. Here's why:

• In offset-based implementations (like ArrayConnection or RelationConnect), the cursor is simply the index of the object in the list at the moment. As objects are added or removed from the list, then the index of a given object may change. In that case, the cursor would change, too. Also, if the list is sorted differently, the same object may have different indexes.
• In GraphQL-Pro's StableRelationConnection, the cursor is a function of the order-by attributes and the object's values for those attributes. So if the object is modified such that those attributes change, or if a new query arrives with different attributes, then the object will have a different cursor.

As such, cursors are really opaque, server-provided tokens for moving forward and backward in the same query.

For stable object identifiers that work from query to query, you'd probably want id 😉

[nimmolo]

LOL what's this id thing?

Thank you very much for the explanation. It sounds like theres not really a way to scoot forward/backward to a post by ID within the context of the original entire query scope, because getting that ID involves a separate query... if i understand correctly.

Ideally i'd like users to be able filter the gigantic list for blog entries to, say, "posts by Santa Claus" in "Virginia", which would still be a very long list, and then jump to the ID of the first post in December 1994, and scroll up and down from there, within Santa's posts in Virginia for all years. It sounds like the only way to put the scroll window in the middle of a big list would be somehow "omnisciently" knowing the item's opaque cursor in that query – but by definition, it is unknowable before you get there.

So I guess there's sort of a "Heisenberg's uncertainty principle" of list indexes, when using opaque cursors. Which makes sense. It just makes this kind of UI maybe not possible.

[rmosolgo]

Maybe what you really want is search/filter parameters, for example, posts(since: "1994-12-01", by: { name: "Santa Claus"}, in: "Virginia"), which would filter the set of posts returned by the field. Using parameters like that, you couldn't page by fixed number of items (you couldn't go 15 posts at a time), but you could jump to certain points in time (back 6 months, etc). Maybe that'd help too.

[nimmolo]

That's what i've got so far, basically. My filtering works (thanks to finally learning some Arel syntax), there are 6 or 7 parameters, and getting filtered posts before or after a given date (or other orderby column) works too.

It's just that i'm getting a bit ambitious with the infinite scroll UI — I believe my users are more interested in searching around a given date, than before, since or between two dates. So I'd like people to be able to skip to an arbitrary milestone in whatever orderby column they've chosen, and then be able to scroll both forwards and backwards from there.

If the user's filtered query scope is already narrowed to since: "1994-12-01", with Relay pagination i believe a fetchMore for previous posts, i.e. {last: 24, beforeCursor: theFirstCursor} called at the top of their results, wouldn't return anything because posts before "1994-12-01" are outside the scope of the original query. Basically i'm trying to maintain an "infinite" scope (as far as the orderby column) while moving the "window" of posts to an arbitrary point in that column.

But not even Instagram provides that. In those Twitter-style interfaces, you're always scrolling back from the present, as far as I can recall. I feel like there may be a valid use case for what i'm describing, but my sense is it's much more expensive computationally, and quite a lift to come up with something as sturdy as the Relay spec, that also would do this.

So maybe my use case is better suited to offset pagination. As far as the "moving target" aspect — where the offset index of the target date that the user is scrolling to changes, because of new entries being added or removed between fetches — in this case, I wouldn't be too worried about missing the scroll target by a few posts.