Hi there! I’m using an invisible repeating group with a search and then using the list as a datasource for other inputs and fields, where i place different filteres on it.
In theory, it would reduce the WU consumption, but in reality it’s consuming even more than a common search on each input. Can anyone check if there’s a specific reason why it’s happening?
0 - This is the invisible search
1 - This is the input that filters the data from the invisible search
Why should this be so?…
In fact, using a hidden RG as a data source, although more logical from a programming point of view will do nothing by to improve WU consumption… in fact it can often increase it, as you’re probably experiencing here.
If a RG is not visible then its data will not be loaded.
Only when it either becomes visible, or when its list of things is referenced elsewhere will the data be loaded…
But only the things being referenced will be loaded, not all of it.
So if you have a hidden RG, and you’re referring to different sub sets of its data elsewhere, you’re most likely performing multiple separate searches for each of those.
So it ends up costing exactly the same, if not more, than it would if you just set each element’s data source to a separate search.
Try making the reference RG visible instead of hidden, so that the data will be loaded into it on page load, and make sure to check the show all items immediately box.
Thank you Adam, this is really useful.
But why would it be consuming more than a search on each cell? Shouldn’t it be consuming the same? Even in the worst case scenario, with every referenced item requiring its own search, wouldn’t that be equal to a search per cell?
I think the possible explanation is -
When you use the RG- it don’t fetch the complete data in once (until you checked - show all lists immediately) - read it here -
So for your case as @adamhholmes mentioned, it needs to make multiple api calls to fetch the data that can be fetched in the one go.
The more searches you do for the same data, the more WU you consume.
There is a WU cost for doing a search, as well as WU cost for returning data.
So data returned from a single search will have WU cost for the data, and WU cost for 1 search
The same total data returned from 10 separate searches will have the same total WU cost for the data, but 10 times the WU cost for the searches.
So from a purely WU cost perspective, it’s better to load all your data in a single search, then filter it client side as needed (of course there are other considerations here besides WU).
As for why this may actually cost more than using separate searches (and this may explain the OP’s issue)…
I’ve observed, in some cases (usually when dealing with a large amount of data), that referring to a RG’s list of data elsewhere on page load, will sometime cause the data to be loaded twice to the page (once to the referring element, and once to the RG - presumably due to the full data not being available in the RG at the time the other element is referring to it - and so the data ends up being loaded twice).
So in these cases you’re not only being charged WU for multiple searches, but also being charged multiple times for returning the same data.
Hi there! Sorry for the delay, thank you very much for the explanation!
@adamhholmes I’ve been spending hours brushing up on the above and have followed the rabbit hole to optimizing my single page SaaS app. As mentioned, loading a main RG and then :filtering to populate the same data throughout the app is not good on WU.
I’m going to use Floppy and as you recommended in this post I’m updating the Floppy variables (similar to updating Custom Sates) to keep up with new item creation.
Appreciate your help across the forum on this topic
