Resuming table offset Table On Back Button

💬 App Building
1

Anyone have a correct approach on using url hash or search params to handle returning to a table's last page when a user navigates back to that app's page or presses the back button from another app's page launched from the table?

I tried and I can't seem to get this to work well. I wish I could {{url.searchParams.page}} inside the table.pagination.offset, but we don't have UI access to that. Every other approach results in either it being wiped out or having to use a complex trigger mechanism on my db query rather than {{table.pagination.offset}} in my db query offset and have auto query db triggers

2

Have you tried putting that offset into a temp var and then running a js to set the previous table page? The only part I think will be difficult is if you are changing the data in the table and that could throw off the row order from the previous table view.

1 Like
3

Hi @FBCRandy,

Is the issue that you aren't able to save a JS variable/hash param/url param that keeps track of what page you want the table to be on?

You can use table1.setPage(1) in a JS Query or run script to change the current page that a table is on.

If a user is changing pages of an app, you should be able to pass variable params back and forth between the app pages, then pass that integer variable into the .setPage() method on the table.

For users hitting the 'back' button in the browser, it gets a little more tricky, as you would need to use URL params to keep track. But as long as you configure URL params as we describe in the docs here, you should be able to have the browser old this number and then can run a script on page load to set the table to the page number you want!

4

I think my issue with the back button is that it rewrites the table page number on load

5

@FBCRandy Ah ok, that makes sense.

Sounds like we need to save the current page to a variable that we can set the table to on page load to ensure that the current page is maintained.

The table1.pagination.currentPage property will have the page number, we just need an event to save this to a JS variable or a hash param/url param which will hold the data and not be cleared out on page change.

Then you can run table.setPage(currPage) with currPage being the param/JS variable.

Let me know if those docs I linked above for setting up hash/url params is helpful and works. We should be able to do pretty much what you described in your original comment but using table.setPage(currPage) instead of table.pagination.offset once you get the offset/page number saved to the params/variable :sweat_smile:

1 Like
6

I've unlinked the page's param so its not hard linked anymore from the page inspector.

Currently I have tried

queryResumePage js query that load on page load and does:


const page = url.searchParams.page;
if (page !== undefined) {
  table1.setPage(page);
}
return true

Then a table event for page change that:

Sets page searchParams to:
{{table1.pagination.currentPage}}

Only runs when:
{{ queryResumePage.data != null || table1.pagination.currentPage !== 0 }}
to avoid writing to it on load.

This however still never results in a page change. I suspect I am too early in the page loading cycle?

I no longer get rewrites which is cool, but no changes.

7

Hmm interesting,

I agree, the script might be running to early, with the component still being written/created on the front end, or maybe the pagination loads last. I was just trying to see if I could set a JA query could set its 'Run Behavior' to 'Automatic' to run on page load but it can't, guessing to avoid race conditions.

You could try a super short debounce to make sure the page loads and then the table's current page is set :thinking:

I would say test your setup with some console logs to see when the script is running as well as logging out the url.searchParams.page to see that it is accessible and changing/not changing at the right times.

If the variable is accessible and correct, and the table1.setPage(currPage) runs but doesn't change the table then it might be a bug I would need to reproduce.

8

Ok it seems like the issue is the total row count.

200ms delay and setting the records count in pagination to be 9999999999 works swell.

What sucks is leaving total row count empty prevents set page from running, and using a cached value on my GetRecordCount.data doesnt allow it to be filled fast enough.

I guess the solution would be something like

{{getRecordCount.data ? getRecordCount.data : 999999999 }}

That said, this would be a interesting feature to add to tables, resume on load etc

1 Like