Provide pagination support for the file list.

[AinzRimuru]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe.
The current web preview does not support pagination, so when there are a large number of files, the loading of the webpage can become very slow or even crash.

Describe the solution you'd like
Add a pagination feature, allowing users to choose the number of items displayed per page.

Describe alternatives you've considered
Just like the display of Google search or the transmission web interface.

Additional context
None

[AinzRimuru]

I have a synchronized mobile photo album folder that contains 27,000 files. I measured the time from clicking the folder to being able to display the file list, which took a total of 90 seconds. During this process, there was almost no observable CPU load in the task manager, so this should be a server performance issue rather than a rendering issue with Chrome.

[provokateurin]

Backend side is available since #45102, but I guess it did not get implemented on the web frontend.

[AinzRimuru]

Several versions have been updated, but this problem is still not resolved. Every time I open the folder of the album backup, it is a disaster.

[susnux]

This is not planned.
The frontend was specifically designed to not make use of pagination as this caused more problems that it solves as we had this in Nextcloud 26. Having a pagination in the files app would mean we start from scratch were we were with Nextcloud 27.
As all frontend API relying on this also would have to be adjusted breaking many apps.

Instead is very likely caused by the backend doing too many requests for all the requested properties.
So the backend would need more performant WebDAV API instead.

---

Backend side is available since #45102, but I guess it did not get implemented on the web frontend.

This is purely for clients not the web ui and was never planned for it, as mentioned the frontend was never (or explicitly not) designed to make use of pagination.

[AinzRimuru]

This is not planned. The frontend was specifically designed to not make use of pagination as this caused more problems that it solves as we had this in Nextcloud 26. Having a pagination in the files app would mean we start from scratch were we were with Nextcloud 27. As all frontend API relying on this also would have to be adjusted breaking many apps.

Instead is very likely caused by the backend doing too many requests for all the requested properties. So the backend would need more performant WebDAV API instead.

Backend side is available since #45102, but I guess it did not get implemented on the web frontend.

This is purely for clients not the web ui and was never planned for it, as mentioned the frontend was never (or explicitly not) designed to make use of pagination.

May I ask if there is any way to browse the photo album backup folders without lagging? At least it shouldn't lag to the point of being unacceptable.

[NETCORTSpille]

I understand the concerns about classic pagination, but performance with large file lists remains a critical issue.

Would it be possible to consider lazy loading / infinite scrolling as an option instead? This would keep the single list approach (so fewer frontend/API changes) while still avoiding the need to render thousands of items at once.

Many other file platforms (Google Drive, Dropbox, etc.) use lazy loading successfully. Even as an optional feature, it would be a huge usability improvement, especially for external storage (e.g. SMB) with very large directories.

[susnux]

Just to clarify: The work amount is always insane to implement this.
Because the current files APIs all require all nodes to be present. It would not only require changes of the files app itself but also all apps with files integrations would need to be adjusted. So every paginated approach needs a complete rewrite of all APIs.

But again, the frontend is capable of handling so many files, if there are problems then they are caused by the PROPFIND on the backend side.

[AinzRimuru]

I retested the folder opening speed. The current synchronized folder contains 31,000 files, and the request took 1.3 minutes.
The interface loaded immediately after the request, and the front-end loading delay was no longer present.
In addition, MySQL is deployed on a hard drive, which may have affected the request processing speed, but the current loading speed of 1.3 minutes is barely acceptable.

Thank you again to the team for their performance efforts. If further performance optimization is not necessary, this issue can be closed at any time.