Hi all,
I am facing an issue related to data being refreshed in read-only grid.
The issue is in my read-only grid, I have navigated to a different page say 21-30. But after certain interval i.e., 30 sec my grid page navigates back to 1-10 automatically. I have a configuration of refresh Interval of 30 sec in the read-only grid. Does the grid refresh configuration update only the grid data or it also impacts the current fv!pagingInfo of the grid?
Reason to add refreshInterval was to update the grid data for user as soon as a new work item is created.
BTW the data field is a recordtype which allows me to use certain other features of grid.
Discussion posts and replies are publicly visible
I will try to answer without seeing your code, I believe when you set a refreshInterval on a read-only grid it refreshes the entire grid and this includes the fv!pagingInfo. So every time the grid refreshes, in your case, every 30 seconds, it resets the pagingInfo to the default page (1-10), which is why you are seeing the navigation reset.
I think it’s best you maintain the selected page manually using a local variable for pagingInfo, so that even after refresh, the grid retains the current page.
I believe (but haven't tested) that this internal refresh behavior is intentional and, to some extent, required. Say you're viewing (and auto-refreshing) a highly variable data set (which Appian has to assume is possible, as it has no way of knowing either way), where at any given minute, the grid could have 3 pages or it could have 10 pages. If you've navigated to page 8 of the data, and the auto refresh occurs, and now there are fewer than 8 pages' worth of data - if your paging info still has you viewing page 8, the grid will throw an unfriendly-looking error. Instead, Appian presumably ensures that all auto-refreshes will be "sanitized" for this behavior by resetting the (internal) Start Index back to 1 for each refresh.
You can probably work around this by querying your data externally (and storing your paging info externally as well), and refreshing your data that way. You'd just need to make sure to check that the data size after any given refresh is compatible with the old Start Index (i.e. the data is long enough that the start index will still make sense, lest it throw an error), and otherwise, reset the start index (which i think is doable, as long as you're reasonably versed in writing this code manually).
Thanks for your prompt response. I appreciate your insight. Although I can implement that code, it may compromise our low-code standards. I believe Appian could enhance the user experience by performing internal sanity checks instead of resetting the index. This would greatly improve the overall user experience.
You could manage the refresh and paging yourself and disable the automatic refresh as the user navigates to a page > 1.
Saahil Mulla said:performing internal sanity checks instead of resetting the index
TBF there used to be zero checks, the only result was an error. Then they added sanity checks, and the result of said sanity check was resetting the start index. I agree that with some effort, this could be made a bit more situationally observant - however your choice now is between waiting 2 - 10 years for Appian to implement this, to stay "low code", or to implement it yourself, to get the functionality you want.
Pagination can be created to handle such scenarios .Normally we do to navigate to and back in editable ones.Better To create Ones in case of issues to have more Control over the batchsize ,movements and refreshes.Just make refreshAfter: "RECORD_ACTION", refreshAlways: true()if you are playing with Records It will Help more on that.