Lowest WUs on Pagination Functions

[boston85719]

I used to use List Shifter free plugin for my pagination. Now I can not, so have to use the Repeating Group.

Setting this up, I need an RG that is to reference for the Total Count of items that match the search criteria.

Set to fixed number of rows and columns to zero, not just for minimizing the size, but also the WU costs. With the fixed number of rows at zero, the search results returned will be equal to the number of rows, zero…so minimize that. You should not incur any costs for the return of a data entry.

This should be height and width of 1x1 and placed into a floating group that is set beneath the page, out of sight and way.

This should be used only to reference the RG list of things count, which will incur a WU cost of 0.20 for an aggregate search.

Then for the RG that will display to the user you will want to use the same do a search for, but apply the operators of :items from :items until (for pagination purposes), as done below.

Using this approach is cheaper than the alternative, which would be to in the display RG use a reference to the hidden RG list of things with operators of items from items until.

I can not explain why there is a difference, but there is a difference. From simple tests, if I were to paginate from page 1, to 2, 3, 4, 5 and back to 1 on a pagination with 12 items per page, in the recommended and cheaper approach I incur 2.73 WUs in total, whereas for the not recommended and more costly approach I incur 3.72 WUs in total. This has been seen consistently in multiple tests of the same approach.

Costs:

Search for pagination: 2.52 WUs
Aggregate Search: 0.20 WUs (needed to reference total number of items)
Real time Search Update: 0.01 WUs

Another thing to note, anytime you need to reference the hidden RG for the count, you are not charged past the first reference, so if you add that value to a workflow conditional or a set custom state action etc. you will not incur additional aggregate search costs.

I lost enthusiasm for this and did not test further beyond paginating through 5 pages…what that means is perhaps, if using this approach and the user paginates through all pages multiple times, it could incur higher costs than if just referencing the hidden RG, but that is not likely as Bubble is supposed to cache search results, so most likely not an issue.

[georgecollier]

Maybe I’m missing something obvious - this looks to be really overcomplicating something that’s already handled. Suppose I have a data table of 100 Things and want to display ten at a time.

1. have an RG with a data source for your search criteria and 10 rows
2. use go to next page / go to previous page for pagination
3. using RG’s List of Things:count for the total count of items that meet the search criteria

Is there a reason you’re not just using that method of pagination rather than relying on hidden RGs?

1 will only return the data for that page
2 will cause the next page to be searched for when desired
3 will run an aggregate search for count at 0.2 WU

Why not just use the native RG pagination using fixed # rows/columns and using go to page of repeating group actions to navigate? Having lots of items from/until, states to handle number of items per page… seems to be more effort than using the native integration which is charged correctly.

I just tested it again to make double sure that it’s being charged correctly.

I have a RG of 10 rows, and went forward ten pages and back ten pages. Each Thing has about 3500 characters of data = 0.011 WU. That should mean 10 searches, and 100 things returned:

10 x 0.3 WU for searches = 3 WU
100 items returned = 100 x 0.015 WU = 1.5 WU
100 items x 3500 characters x 0.000003 per character = 1.05 WU
Count = 0.2 WU

= 5.75

The logs show it costed 5.85 which is about right - some of my data will have had more characters than others which could well make up the 0.1 WU difference. Going back pages doesn’t re-charge WU as they’re already saved in the browser (you’ll notice going back pages is faster than going forward for this reason).

So, I don’t see why you wouldn’t just use the built-in method of pagination which is way easier to setup and maintain and costs exactly as much WU as it should. Additionally, I don’t see how any method (assuming you’re not increasing the page size…) would result in cheaper WU than the simple case I wrote above. I’m open to being enlightened on this or maybe I’m embarrassing myself and missing something obvious to everyone else but this has always worked as expected for me.

Edit: I think the costings of what I showed are basically in line with your ‘cheaper’ method, except the one I mention just uses a standard search and doesn’t use items from / items until at all to make it easier to handle, so I’m trying to understand why you wouldn’t just do that

[boston85719]

@georgecollier

Maybe I’m missing something obvious - this looks to be really overcomplicating something that’s already handled.

Bubble doesn’t expose all the necessary values to get pagination just right. Need a total number of pages value and current page number value.

@georgecollier

Why not just use the native RG pagination using fixed # rows/columns and using go to page of repeating group actions to navigate?

Allow user to select the number of items per page…not possible with fixed number of rows, and when using the custom CSS to alter the fixed number of rows to be dynamic because Bubble has not enabled a dynamic value for the number of rows, it is just not possible to get the function for allowing a user to choose the number of items per page.

@georgecollier

1 will only return the data for that page
2 will cause the next page to be searched for when desired
3 will run an aggregate search for count at 0.2 WU

That is the same as the approach I describe in the tip.

I was also curious to see these side by side, so I added an RG with fixed number of rows, and did pagination with just using previous page and next page per workflow actions.

The search in the fixed row RG is the same as in my RG with no fixed number of rows…not sure what might be the reason for the difference, perhaps them being on the same page at the same time is causing some difference in the WU consumed attributed to one versus the other, but I see that the fixed number of rows is costing more.

[georgecollier]

@boston85719

Allow user to select the number of items per page…

Ah, fair enough hadn’t thought about that one.

[boston85719]

@boston85719

I was also curious to see these side by side, so I added an RG with fixed number of rows, and did pagination with just using previous page and next page per workflow actions.

The search in the fixed row RG is the same as in my RG with no fixed number of rows…not sure what might be the reason for the difference, perhaps them being on the same page at the same time is causing some difference in the WU consumed attributed to one versus the other, but I see that the fixed number of rows is costing more.

You’ve had a lot of good insight on my other posts about WUs…what do you think is the reason for this differential? Do you think it is just because they are both on the same page and so maybe get attributed in some weird way? Because the total of the two is about what I’ve seen with just the one.

[georgecollier]

@boston85719

Do you think it is just because they are both on the same page and so maybe get attributed in some weird way?

Best way to find out is to try them on separate pages.

Two RGs, one with List of Things:items from X:items until #pageSize, and another with fixed row of pageSize rows, should always have identical WU consumption, so long as there is no other difference between them (and this is what I found when comparing :fixed rows with your items from approach - they were basically equal)

[boston85719]

I bet the attribution might come to a speed thing. Could be that the first 0.50 WU attributed to RG with items from items until was on some step in pagination where it was slightly faster than the fixed Row RG, while most of the time the fixed Row RG was slightly faster, causing higher attribution of WUs.

[mac2]

Man, I really enjoy watching you two discussing back and forth recently.

[georgecollier]

It’s just us trying to decode WU and hopefully leave some breadcrumbs for future readers

[mghatiya]

Summaries of all these discussions and explorations should ideally get documented somewhere and be put up.

Current documentation by Bubble on WUs is really really primitive and doesn’t go to these depths for different use-cases.

[randomanon]

Yeah I would love if someone could put together a “black book” on WU savings tips. Not the usual stuff about general optimization practices but the high-yield buggy stuff that has to do with WU being derived in a haphazard statistical manner. Like for example, search:count is 0 leading to 100x more WU consumption than search: count <1 for literally no reason.