Cursor-based server paging fails when triggering

I'm using GraphQL and server-side paging with the cursor-based method and scrolling.

If I want to trigger the dataset to reload, i.e. after editing data, it applies the last used value of afterCursor, but for the whole table.

For example, if I have 7 records and I'm fetching 5 records at a time:

  1. Viewing the table triggers the first fetch of 5 records, with a resulting hasNextPage==true and correct afterCursor returned.
  2. Then the next fetch of the remaining 2 records using the afterCursor is performed in order to allow scrolling to view the final 2 records.
  3. Now, I want to edit a record, which in my case uses a form, so I go to the form and change data and click Submit.
  4. In my GraphQL mutation that is triggered by Submit, I have an onSuccess event to trigger the original GraphQL query for the table.
  5. This causes a fetch, but with the afterCursor still applied, so it only shows the last 2 records, even though the result also has totalCount==7 still.

Is there a way to reset the afterCursor on the table that was applied due to the scrolling before triggering the reload?

Hey @ekaiser!

Do you happen to be using GraphQL Relay cursor based pagination or just standard Cursor based pagination? If it happens to be Relay, could you try using regular Cursor based and see if that might be a workaround?

You also mentioned scrolling - do you have your table set to scroll as well?

1 Like

I believe it is set up as Relay-based pagination, but I'm just using it like regular Curosr-based, I believe. I'm not too sure whether it is or not, since I'm using the Hot Chocolate GraphQL Pagination factory and it does it for me.

Here is an example of the response (with most data removed for brevity), followed by the settings used for the Retool table:

{
  "data": {
    "activities": {
      "totalCount": 7,
      "pageInfo": {
        "hasNextPage": true,
        "hasPreviousPage": false,
        "startCursor": "MA==",
        "endCursor": "NA=="
      },
      "nodes": [
        {
          "id": "e8a0525d-d209-4ec8-9035-ca2a33bae142"
        },
        {
          "id": "44c83c65-81db-488c-aafb-f43d233bb88d"
        },
        {
          "id": "1d643d5a-a524-4e44-a1da-827d3e3b1180"
        },
        {
          "id": "4ef749a8-f1c2-45c8-84a3-322f3f1763d8"
        },
        {
          "id": "a788a2ee-d441-4de6-9249-dc83fc9c422c"
        }
      ]
    }
  }
}

image

As you can see, I was using the Scroll option for Overflow, but Pagination does the same exact thing. The paging works fine at first (even going back and forth between pages), but if I go to page 2, and then trigger the datasource to refresh the data after a change, the table seems to think that it is on page 1, but shows the last 2 results, and won't let me go back.

OK, so I just realized you had an option for GraphQL Relay-based Cursor in Pagination Type, and now after changing it to that, it works!

Thanks for your help!

Alright, good to hear that works :slightly_smiling_face:

Thanks for the additional context as well! We're looking into why relay-based isn't functioning properly on our side. And we can report back here when it's fixed.

To be clear, selecting GraphQL Relay-based in Pagination Type works for me, at least when I have the Overflow on Pagination rather than Scroll. My original issue was that I did not have Retool on Relay-based even though my server was doing it, because I simply didn't know what that was at the time.

The only remaining issue that I can see if that Scroll option still does not function correctly, regardless of what Pagination Type I use.

Got it, thanks for that clarification! We're looking to release a .refresh API for tables soon that should help give more control over when table pagination is reset that should help in both cases.

1 Like

Just a heads up that the .refresh API has shipped with 2.105.0 @ekaiser!

1 Like