Having repeating group to show user’s items_until
How to make the Show button to hide when there is no more users to show?
Challenge here is due to the list dynamicity number of users shown. Thanks!
First, determine the total number of things.
Then use the following condition to hide the button when they are all loaded into the RG:
when RG's list of things: count is Total Number of Things
One more Search? When Search button is clicked to count the total number of items on the list, and than use as the state?
Reason for this feature (Load more) is to reduce the WU. Does the count affect the WU here as well? (…List of users:count) Or it will reduce dramatically the WU instead of displaying 20-30 items right away (depending on the visitors size screen i guess)?
Thanks @adamhholmes
You can’t use RG’s List Of Users Count (that will always be the same as the number of things the RG is currently showing).
You need to get the total count of things you’re intending to show, using Search For Users: count
Search: count is an aggregate search, and does not return any results… only the number (count)…
1 Like
The search for count will then be a light-weight WU compared to the regular search for (users) that fetches the whole data type of each user and related linked data types. Despite having some conditions on the search, for example, type of user (6 different types), is this then paid off to add the “load more” button with the condition to display 10 items (plus load more) due to this additional search to count the number of users on the list each time the search is triggered?
Yes… an aggregate search only ever costs 0.2 WU
I’m not sure I fully understand the rest of your question… but a few things worth considering…
Obviously, loading 10 items costs less WU than loading all of them at once (say 100 items)
But if a User hits the Load More button 10 times, and ends up loading all 100 items into the RG, it will have actually cost more in WU that it would have done just to load all 100 items at once (the overall amount of data will be the same, but you’ll have made 10 searches, instead of just 1).
So the WU saving here comes from the assumption that most Users won’t click the Load More button (or might click it once or twice only).
If you’re expecting most users to end up loading all of the RG items then, at least in WU cost terms, it’s better to load all the data at once. (the same goes for using lazy loading - in some cases it can cost more WU than just loading all data at once - but of course that depends on the specific numbers involved, and what percentage of users will end up loading all the RG data).
2 Likes
This gives a clearer idea of WU and Search and how it work.
How about if the default Search for Users is Until_items:10, and then to load more, it changes the state to Until_item + 10, which doesn’t necessarily do the Search again?
Default search is there, which follows the number in states, so in this case, each time the state is changed, and here Data sources “follows” with it, it will do search over and over? The whole search, or only until the number in the state?
If search only searches for the first 10, and then with Load more to display 10 more, it will be a total of 30 items searched as we count the previous 10 items, and now 20 in total = 30? This is the math here?
It does do the search again (check in dev tools to see for yourself).
The first search returns the first 10 items.
when you update the custom state + 10, the search is done again, this time for the first 20 items, 10 of which are already loaded, so only 10 more will be returned… but it’s still another search (an additional 0.3 WU plus the cost of returning those 10 items).
1 Like
But then the math is good.
If Search loads first 100 items (users), it 0.3 WU plus 100 items total search WU)
Or if we use states with 10 clicks to add 10 items each time, because previous items are loaded, so the difference is only in 0.3 WU per each load?
Yes each search costs 0.3 WU just for doing the search.
So doing 10 searches costs exactly 10x more than doing 1 (not accounting for the returned data, which remains the same in either case).
So if we assume a data return cost of 1.38 WU for 10 items (which is exactly what it costs in a quick test I just ran in an app of mine, and is a pretty reasonable average for a light datatype, but will obviously vary massively depending on the actual data involved), then doing a single search here for 100 items will cost 14.1 WU (1.38 x 10 = 13.8, plus 0.3 for the search itself).
Whereas doing 10 separate searches will cost 16.8 WU (1.38 plus 0.3 = 1.68, ten times) which is almost 20% more.
In any case, retrieving the same amount of data via multiple searches will always cost more in WU than retrieving it in a single search (obviously)…
So the question is how often the full amount of data will likely be requested, compared to just a subset of it.
If, as I said previously, the assumption is that most users will only ever load the first 10-20 items, then even though it will cost more in WU for those users who load all 100, the overall average WU will likely be less than loading all the data every time.
Whereas, if most users always load it all, the overall WU cost will be higher.
2 Likes
Big one! Need some time to think through, test, examine and evaluate. Brb 
Hi @adamhholmes!
Finally bit of time came as working season is “closing”…
It seems for the “Show more” button to be implemented
For us to wrap up here, is to go back to the begining and how to count total number of search results, as there are different filters, depends on which user chooses, so we might for this “simple” custom state add several more conditions when the search button is clicked, there are already several different actions when search button is clicked while each having own condition depending on the filters.
Any easier turn around here?
This topic was automatically closed after 70 days. New replies are no longer allowed.