Using Pagination and cursor how to refresh existing results for use in grids

Help
3

I’m getting the after cursor that looks something like this for some of the indexes and in others like you sampled:

after: [
    123123123,
    Ref(Collection("Sales"), "266869347503309324"),
    Ref(Collection("Sales"), "266869347503309324")
  ]

And like your sample, for some indexes I get an after cursor that has only 1 ref ID returned. While I may understand potentially the reason as explained on the link I found in the forum for similar struggle, it doesn’t make it any easier to develop in a dynamic way for with the lack of consistency.

I don’t understand how I wouldn’t have to track the details within the cursor if I have to send (serialize) those from the stateless backend to a Javascript frontend over a RESTful API call so that it can be consumed in a grid and sent back over to the backend on the back/forward/first page/last page/refresh requests so that I can get the proper page?

Typically, you don’t have to track details within a cursor. Simply use the value of the after or before cursor (depending on which direction you want to move) in subsequent queries.

The frontend javascript client app’s grid has a refresh of current page feature. This is an existing app that is being upgraded and decision was to use Fauna as the DB that the Java backend communicates with on behalf of the frontend. So we can’t remove functionality. But that’s exactly what I’m asking – how to do a refresh of a specific page as there’s no documentation around that which I could find.
So if I’m understanding what you’re saying, then I have to introduce in addition to tracking the after and before cursors on each request that has to serialize them down to the frontend Javascript client, I now have to also add logic to a completely stateless environment to keep the cursor of each request. Ouch. I was afraid of that. Makes it even more useless data to send back and forth per each page to/form client.

If you are concerned that page x has refreshed since you first fetched it, and you want to keep the pagination consistent in your UI, keep track of the cursors returned from each page, and then re-run page x’s query.

I don’t have any code samples, but as I suggested in my original post, having a consistent after/before cursor (not sometimes it’s an array of 2 rows, sometimes 3 rows, sometimes x) would be a start. And if it’s enough to pass in the JSON looking syntax with just the ref ID for after/before then I could just store pass the ref ID to the client and the client can pass it back to the backend and backend can build the same looking JSON object dynamically substituting the ref ID that would already be less to serialize and easier to build dynamically if offsets are not possible.

For example, a lot of frontend grids have a functionality to skip to a specific page, i.e. 101st page out of say 500 pages. I see no way doing that with current pagination without a lot of additional effort for a developer.

Or what if I want to leverage the frontend grid’s column filtering that does >, <, AND,OR,CONTAINS,NOT CONTAINS,EQUALS,NOT EQUALS, and column sorting as part of the pagination in a frontend/backend approach that has to account for building the queries dynamically it seems so difficult with the current implementation. The amount of backend code (at least with your Java SDK) that this appears to require to make it dynamic I cringe.

We definitely want to improve the developer experience when using our drivers. If you have any suggested code samples that would notably improve the experience, please add them here.