Table afterCursor persisting a new set of data

Hi all, I hope you are well.
I have a problem with implementing server-side pagination in a table that uses a RESTQuery as mean to receive data from a server.

In the query I use the afterCursor of the table to download new data as the user scroll, like this:
"cursor": "{{ _.isNil(walletTbl.afterCursor) ? "" : walletTbl.afterCursor }}"
The query has other parameters than when changed, should not use the cursor of a previous query.
So I coded a small JS script to reset both the query and the table when needed:

await WalletLedgerList.reset(); <-- query
await walletTbl.setData([{}]); <-- table

But I discovered that the parameter afterCursor in the table, persists this script, and therefore when the query gets called again it throws an error due to the wrong cursor being used.
I tried using in the query the parameter hasNextAfterCursor provided by the table, but retool warns me for a circular dependency, and it doesn't solve the issue.

Could you please tell me if I'm missing something in my implementation?

Thanks for your help and have a nice day,

Hey @Matteo_Graizzaro!

Tables also have a recently added .refresh() API that might help here. Have you tried playing around with that at all and doesn't it fit into your use case?

Thanks for your help @Kabirdas. Unfortunately I tried adding it below the clearing of the table data, but if I inspect the module table by exposing it as an output, the afterCursor parameter is still populated.

await walletTbl.setData([]);
await walletTbl.refresh();

I'm asking myself if my method is wrong, but the docs explicitly uses the parameter in the query without further processing it.


:thinking: are you using GraphQL Relay cursor based pagination or regular Cursor based pagination? It looks like there may be a bug on our end that's causing the refresh API to not work properly with GraphQL based pagination.

Nope, just pretty old regular Cursor based server pagination.

I just had to code a more complex solution for the "Total row count" because I discovered that even if "Has next page" is false, as long as the number of displayed rows has not exceeded the total, retool keeps asking for more, which does not makes sense, but I don't think is related to my problem with the table.

In case anyone stumbles across this thread - this seems to be an issue specifically for tables that are embedded in modules. We'll let you know here when there's an update on the bug!

I've found a temporary workaround. When setting the value of your cursors, you can return null when the selectedPageIndex === 0.

So the value for the cursor would look something like:

table.selectedPageIndex === 0 ? null : cursorValue