So this is super easy to test now, with the new real-time WU reporting…
But it’s interesting to understand what’s going on.
First, lets look at the basics - types of searches and associated costs.
Search: a regular search expression costs 0.3 WU, plus the cost for the amount of data returned to the page - which obviously depends on how much, and how heavy the data is. It returns the data to the page.
Aggregated Search: such as search:count costs 0.2 WU and returns just a single number (the count) of the search results.
An interesting thing to note (and I’ve mentioned this before)…
When loading a list of things into a RG using a search, an agg search is also always performed (even if you make no reference to the count anywhere on the page).
Compared to loading that same list into a custom state, where only the search is performed.
So, loading a list into an RG with a search ALWAYS costs 0.2 WU more than doing the same thing with a custom state.
So, what’s the best way to get the count of some things inside a RG cell?
Well, there a 3 ways to do it:
-
put a search: count inside each cell
-
Load all the relevant data into a different RG first, then use that list filtered:count inside each cell
-
Load all the relevant data into a custom state first, then use that list filtered: count inside each cell
So which is better?
Let’s look at what happens with each:
1 - putting search:count inside each cell. Here, exactly as you’d expect, an aggregate search is performed for each cell (at a cost of 0.2 WU each time). So if you have 10 RG cells, there will be 10 agg searches, costing a total of 2 WU (regardless of the amount, or size, of the things being counted)
2 - Loading ALL the data into a RG first and filtering it inside each cell. This is interesting, as it’s not at all what you’d expect.
Here’s what happens: you get charged for a search, plus a agg search for loading the data into the RG in the first place. lets just say the search costs 1.41 WU (0.3 for the search, and 1.11 for the returned data), plus the agg search that all RG searches consume… so far that’s 1.61 WU.
Then, on top of that, there’s another 10 agg searches performed - one for each cell… so another 2 WU (0.2 x 10).
That totals 3.61 WU
3 - Loading all the data into a custom state, then filtering it inside each cell. This behaves as expected. The data is loaded once, costing just 1.14 WU (0.3 for the search, and 1.11 for the data), and that’s it. There are no agg searches here, as the data is already on the page.
So the total cost for this is 1.14 WU (less than a third of the cost of the previous method)
So, there is a clear difference - if you load data into an RG and filter it inside another RG, you get charged multiple times for data that’s already on the page (I’ve observed this multiple times ever since WU became a thing)
In this particular case, loading the data into a custom state, then filtering it in the RG cell is the cheapest WU cost method.
If you had less RG cells, then doing a search:count inside each would be cheaper.
But also remember that WU cost is only one consideration here... you also need to consider performance (i.e. how much data you're loading to the page)... loading too much data to the page can slow things down (or cause the browser to crash), so if you're dealing with a *lot* of data, then loading it all onto the page, just so you can count it is not a good idea.
In that case, doing a search count inside each cell, even though it will cost more in WU, is definitely better than loading thousand of items to the page in a custom state.
So. as with everything in Bubble, the best way to do something (in both WU cost and performance) will depend on the specifics of your app (and the data you’re working with).
