Paging an editable grid, and persisting the data across pages in the UI

Editable grids don't allow pagination. When you say "persist the data across pages", I'm assuming that you're updating the data in the grid and want it to stay there. If I understand you correctly, here is the sample code to achieve the task: https://docs.appian.com/...editable-grid

If I misunderstood you, could you please elaborate a little further about your use case? Do you want to create custom pagination? Or do you already have it and want to persist the data when you paginate through it?

So quite a few things you'll have to do.

1.  Either query all the data up front and store it in one location (a local variable), or if that's going to be a really bad performance hit, then query the first page of the data and store it in that local, and when startindex goes up, you'll have to grab more data and append it.

2.  Create a SEPARATE local variable that stores the first page of the data.  local!queriedData and local!currentGridPageData may be good names.

3. Populate your grid with the data from the second one, local!currentGridPageData

4. When you make changes to the row, update the row on BOTH local variables.

5. Create custom controls that handle your paging and batchsize.  This is where this whole idea is kind of nice, because you can use ANYTHING.

6.  When you hit one of the custom controls, page data from the first one and put it into the second one, which puts only part of that data in the grid.  Never re-query the data again, or it wipes out the changes you just specified you want to persist.  If you don't have the data you need in local!queriedData, get the next page of data from query and append it to the end ONLY.  When you go back to a previous page, you are only paging data for the grid (which goes in the second one) from the data in your first one.

7.  The first localVariable (local!queriedData) will eventually contain all changes across all pages.  That needs to be sent to a rule input and saved when the form is submitted.  Then that can go to a PV and be written to the DB / External Service.  Otherwise, of course, there was no point to this form.

A bit of work, and you'll probably eventually be storing all rows of the whole database in local!queriedData, so this is only viable for a small enough dataset.  The performance will get really, really bad if this gets really, really big.