@larivibi
I'll start with the later part - Galleries were designed (IMO) around the fact that people seem to want to show thousands of records in a gallery - because their users really want to scroll through a lot of records to find what they want (sarcasm). So, this causes issues with performance because not only does the app need to get all the data, but the gallery needs to render it all. That is a pretty big memory footprint. So, they made them to page on their own. They will get a certain number of records first and then as the user scrolls down, continue to get the additional. This minimized the initial performance issue and the memory issue. So, they have that little gem in them. It can be a blessing and a curse depending on how you use the Gallery.
For example, using your approach to having a Gallery be a "sub gatherer" in order to do a Distinct on it to get what you want (because yes, Distinct is not delegable). So, let's say you have 2000 records in your datasource. If you set the Gallery to that datasource to get the records and then do a Distinct on the AllItems of the Gallery, then you will run into problems because the Gallery will not have loaded all of the records...it has to page them on demand. How do you demand them...you have to scroll to the bottom until it is no longer gathering new records. This is problematic because you either have to have the user scroll it, or, if it is hidden, then you need to scroll it by selecting the last record with the Select function (select for a Gallery lets you not only select the gallery, but also a row). The problem is...you need to specify the row - the last one. But how do you know what number that is?? Well, you could CountRows on the datasource to get the number of rows - BUT, CountRows is not delegable!! So, in your case, you would only count rows of 3.
The reality is that to do delegation properly and handle situations like this, you really have to think from the data side of things. If you are using SQL for example, you can offload a lot of the non delegable actions into views. Example, you can get the distinct in a view and then just get that view in your app (of course with 3 records as your limit, you'll still only get 3 records). But, based on the above Gallery scenario, you could also have a view that returns the count of all the distinct...so you could select the last row in the gallery and have them all.
In the case of SharePoint, you have to plan for these things. Planning around this is done in a few ways. One would be to utilize PowerAutomate to create a separate list of all the distinct values. You could also do it in PowerApps itself, but this is a good job for a flow. Then, you will have a list with just the distinct values to work from and not need to issue the non-delegable Distinct function.
How do you get a record count...well, you can't. But, you can again plan around it with a flow. If you have another list with even just a single record and a column for each data list that you are interested in and a numeric count of the records in those lists, then you can have flow fill in the current count of records and your app can just refresh that datasource and get the record count.
There are a lot of little ways to plan around delegation issues and record limits. Most of it becomes very specific to the scenario as opposed to "do it like this all the time".
As for the documentation...yes, there is a LOT of details missing in them about these situations. I think they just left it up to the forum to fill in the blanks 😀
Hopefully all clear and helpful for you.
