I have an app where I have tables counting currently around few k/10 k things.
I want to display them to the user - main interface when they log in - they see all the orders/operations we do.
Currently I have a pagination - and here the issue is that count of pages - which is later used to assign numbers to paginated page, costs us 20-30% of app WU consumption (as everybody stays/returns to this page - making it static didn’t help much). We have tried to build infinite scroll but this one lags our app - so it’s not very efficient.
Is there any way to build pagination / bigger data list in an effective way?
On this list we also have filters (either in search of in filtered parameter or advanced) and we have a search for one of it’s elements + 2 aggregated searches that return costs.
I am currently running into this exact issue. I don’t understand why running a count of things that have already been searched for, uses so much WU. In theory they’re already queried, and the RG ‘knows’ how many there are.
I’m following along to see if anyone else has some good insight into ways around this.
Is this Pagination using the API or you are using the front end to “do a search for” on the repeating group?
If front end:
When you arrive to the page and load the RG initially you have the full count right?
Whatever the datasource you need to load into the RG, use that same search’s approximate count .
couldn’t you just set the State once on the page such as (RG-total-count) and then the page is the Total Count / number of results shown (e.g., 20 rows): ceiling
so for example
2143 items
/ 20 rows
= 108 pages
Use {show partial list} on the RG settings
1 Like
I ran into this issue while building early on. infinite scroll is nearly impossible on bubble unless you’re looking for a laggy glitchy mess.
I solved this issue via a combination of @keith’s ListShifter for Pure Pagination Control, and @zelus_pudding’s OmniSearch that connects my Bubble Database to Algolia or Typesense, allowing me to have blazing fast searches without using crazy amounts of WU or Bubble Resources, or even having to worry about scalability. Omni just went live a few days ago after being in Beta for a year, so this is good timing.
Any Questions Lmk
2 Likes
If in any moment I have to use count it’s already a method that I am trying to avoid.
I have build a pagination without the count.
Removed the page numbers fancy pagination where we had 1st, -1, current, +1 and last. So now we just get results, paginate and have <> to nav.
Infinite scroll was a reaaally hungry beast in terms of app performance.
Thanks guys and girls for the advices!
