Perf: Optimize trashed pages

[Koc]

📝 Summary

In our organization we are actively using Collectives. And currently we have 2 performance issues with trashed pages:

• queries in the loop (each trashed page loaded using separate query) -> load all pages using single WHERE IN query
• trashed pages loaded immediately on each Collective opening -> delay loading until popup with trashed pages opened

This PR aims to fix both of this issues

🖼️ Screenshots

🚧 TODO

• I can implement lazy loading for deleted collectives as well, just confirm that you ok with that

🏁 Checklist

• Code is properly formatted (npm run lint / npm run stylelint / composer run cs:check)
• Sign-off message is added to all commits
• Tests (unit, integration and/or end-to-end) passing and the changes are covered with tests
• Documentation (README or documentation) has been updated or is not required

[mejo-]

Thanks a lot @Koc, once again much appreciated!

Code changes look good to me. I see two problems though:

1. Deleting a page now results in an error if the trash was not opened before, as deleting the page will move it in pages store from allPages[collectiveIndex] array to allTrashPages[collectiveIndex]. I'd like to keep this logic if the trash pages already got loaded beforehands as this means that allPages and allTrashPages stay in sync. When notify_push is enabled, this even works for pages that got deleted by a remote user.

Maybe we should just change the logic to check if allTrashPages already got initialized for the collective in question and depending on that either only drop from allPages or also add to allTrashPages.

2. Now getTrashPages() is called each time the page trash is opened. I wonder whether we should check whether allTrashPages already got initialized for the collective in question. Since we cache the store in browser local storage nowadays, we probably still need a way to ensure it gets updated after switching the collective.

So I'd suggest a variable to track whether allTrashPages got initialized for a particular collective that always holds the collectiveIndex for the active collective. If the trash page gets opened and the tracking variable is not set to the current collective yet, we fetch the page trash. If it's already set to the current collective, we don't.

What do you think?

[Koc]

Hey @mejo-!

Deleting a page now results in an error if the trash was not opened before

I don't see any errors, see attached video with opened console

So I'd suggest a variable to track whether allTrashPages got initialized for a particular collective

Good catch, added loadedTrashedPagesPerCollective. Maybe not the best name, feel free to suggest or push into branch

nextcloud-trashed-pages-2026-03-09_00.58.30.mp4

[mejo-]

I don't see any errors, see attached video with opened console

You'll have to open a collective where the page trash was never fetched before to run into this bug. I'll push a fix for it.

[Koc]

Thanx for pushing fixes and quick merge 🙏 . The only one thing that I thought that we should store flag that trashed pages are loaded per collective id, not globally.

Imagine that we have few collecties and each of them has their own trashed pages. We load trashes pages for collective 1, set flag as true, then open collective 2, try to open trashed pages popup but flag is already set to true

[mejo-]

Imagine that we have few collecties and each of them has their own trashed pages. We load trashes pages for collective 1, set flag as true, then open collective 2, try to open trashed pages popup but flag is already set to true

That's why the flag is reset each time the collective is switched. And as the flag is not persisted in browser storage, its scope is limited to the current browser tab. The idea was to make sure that each time a collective gets opened (either by browsing there or by switching the collective from within the app), opening the page trash for the first time will fetch the trashed pages.