Table Pagination in Canvas App vs infinite scroll

[Anonymous]

I have been designing a table in PowerApps with a Canvas app. The table is not responsive currently and only fits about 10 rows by default. 

The data in the table come from the DB. My engineers are suggesting to fetch list and have the user scroll through the 10 rows and have the BE fetch the next set of results. My UI design called for a pagination. They seem concerned about data retrieval that way and wanted to get people's opinion of this? 

The reason I am going for the pagination route is that currently the table is "not" responsive and so with large data sets of 100+ records, when you scroll inside the table it is very clunky currently in our dev environment as it takes awhile to get the records and then you see white space until the table loads the new data set. 

[PowerAddict]

What exactly are you doing to implement pagination? I dont see any issue with this. Also, what are the concerns they have with this logic?

---
If you like this reply, please give kudos. And if this solves your problem, please accept this reply as the solution.

Thanks!
Hardit Bhatia
The Power Addict
https://thepoweraddict.com

[Anonymous]

If performance when getting data from the DB is slow. If suggest getting your 100+ records onstart of the app and put it into a collection.

Then you could paginate data from the collection instead of calling the DB every 10 rows.

You could also speed up the responsiveness of the table/DB call by restricting the columns you are pulling back.

To improve performance of the table being displayed, Galleries are slow when you've got lots of labels and text boxes in each row and have hundreds of rows. So if you can reduce the amount of labels/boxes/buttons that will also speed it up.

Lastly, if performance is still a drag. You could use a Data Table instead of a Gallery. They are much more limited in terms of look/feel, but dang are they faster than Galleries.

[paulbeck1]

There are basically two approaches to paging: Pull large data sets and manage the paging with the locally cached data or use the query  to do the paging on each request.

As a general rule, option 1 is better.  The amount of data does not significantly cause performance issues, the heavy lift is generally the query not the amount of data over the wire.  Assuming your dataset isn't over 2000 thousands of rows, option 1 is the way to  go.  If it is taking a few seconds, look for a point to load the data perhaps on app initialization.

Option 2 works well for extremely large data that needs to be sliced and/or HTTP API's.  If you data is dynamic (i.e. could be anything from a big data set), you want to query specifically so the user doesn't need to page or scroll.  

Summary, it depends.  Basically map of the data-set and requirement and pick the best options.  For instance, on a data-set of 4 million rows, I don't allow paging, if the user can't narrow it down, I doubt they are going to page around to find the data.

[v-xida-msft · Accepted solution]

Hi @Anonymous ,

Do you want to display your table records using Pagination functionality?

Based on the needs that you mentioned, I think the Gallery could achieve your needs. The user @hpkeong has provided a detailed solution for this scenario, please check the solution within the following blog:

https://powerusers.microsoft.com/t5/News-Announcements/Pagination-Features-Esp-for-PC-or-Tablet-Mode/ba-p/24077

Please consider take a try with above solution, check if it could help in your scenario.

Best regards,