Allow basic bi-directional windowed pagination according to Relay spec

[codepunkt]

The hasPreviousPage provided by PageInfo on connection queries seems to be false in circumstances where i would expect them to be true - which means that basic bi-directional windowed pagination can not be performed satisfyingly at the moment.

A simple example where you have a list of 5 posts (ids "1"-"5") in the database and query postsConnection, paginating forward using a first limit and an after cursor:

first	after	startCursor	endCursor	hasNextPage	hasPreviousPage
2		"1"	"2"	true	false
2	"2"	"3"	"4"	true	false
2	"4"	"5"		false	false

We might only want to show 2 items at a time with forward & back buttons. The hasNextPage tells us reliably if we can expect another page or should disable the forward button. The hasPreviousPage doesn't do so. While we can still try to fetch the results from the previous page on click of the back button by querying with a before with the value of the startCursor, we don't know beforehand if we will get any results or simply turn up empty.

What is expected is instead this:

first	after	startCursor	endCursor	hasNextPage	hasPreviousPage
2		"1"	"2"	true	false
2	"2"	"3"	"4"	true	true
2	"4"	"5"		false	true

The same problem occurs when paginating backwards using last and before instead of first and after - hasPreviousPage is correctly set but hasNextPage is always false.

The relay spec states:

hasPreviousPage is used to indicate whether more edges exist prior to the set defined by the clients arguments. If the client is paginating with last/before, then the server must return true if prior edges exist, otherwise false. If the client is paginating with first/after, then the client may return true if edges prior to after exist, if it can do so efficiently, otherwise may return false.

hasNextPage is used to indicate whether more edges exist following the set defined by the clients arguments. If the client is paginating with first/after, then the server must return true if further edges exist, otherwise false. If the client is paginating with last/before, then the client may return true if edges further from before exist, if it can do so efficiently, otherwise may return false.

Therefore i propose that you handle this by returning true if edges prior or after exist regardless of pagination direction. That would be extremely helpful!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[helios1138]

Just started to explore Prisma and literally the first thing I checked is whether pagination works correctly/as expected and it wasn't :(

[kgoggin]

Any word on if there are actually plans to implement this? I know it was requested to be listed as a "feature" but it feels a lot more like a bug when you consider how the connections spec is expected to work. I'm unable to ever get hasPreviousPage to come back as true, which begs the question of why it's even there to begin with?

[DominikMueller64]

I fully agree with @kgoggin that this feels much more like a bug. If you want so, a bug in the relay specs, because

If the client is paginating with first/after, then the client may return true if edges prior to after exist, if it can do so efficiently, otherwise may return false.

is not so usefull. I think it should return true if it can so efficiently, but rather null if it can't, otherwise you actually get wrong information.

From any programmer's practical point of view, this is a bug.

[danielmahon]

Haven't gotten hasPreviousPage to work properly, but I was having problems getting hasNextPage to work until I figured out the right combination of prisma-client calls in my resolver, here is what worked for me in case it helps anyone:

Hint: I'm ONLY passing the where arg to the aggregate call, but all args to pageInfo, that way aggregate.count will return the total of filtered items but ignore the pagination.

...
imagesConnection: async (parent, args, ctx) => {
    const edges = await ctx.db.imagesConnection(args).edges();
    const aggregate = await ctx.db
      .imagesConnection({ where: args.where })
      .aggregate();
    const pageInfo = await ctx.db.imagesConnection(args).pageInfo();
    return { edges, aggregate, pageInfo };
  },
...

[YannisMarios]

I totally agree with @DominikMueller64. Common sense says that this is a bug.

[hughevans]

It was like this in GraphQL Ruby for a while too. Because it results in extra SQL queries and many pagination scenarios don’t require it they made it optional rmosolgo/graphql-ruby#960.

[faurehu]

I'm not really adding anything to the discussion but the thread seems to have gone stale and it needs a bump. I just wanted to say I was about to report a bug but then "similar topics" suggestion pointed me here.