Persist status of page tree expansion

[david-venhoff]

Short description

This pr stores the expansion state of the page tree in the browser session storage in order to reconstruct the previous state after navigating back to the page tree. Since loading the dynamic page tree takes a few moments, it could make sense to display some sort of loading indicator, before the page tree can get expanded.

Proposed changes

• Keep track of page row expansions
• On page load, or when the dynamic subpages loaded, restore the previous tree expansion

Resolved issues

Fixes: #1245

[codeclimate[bot]]

Code Climate has analyzed commit c27f836e and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 96.4% (50% is the threshold).

This pull request will bring the total coverage in the repository to 75.3% (0.0% change).

View more on Code Climate.

[david-venhoff]

The latest commit should improve the performance of restoring the page tree state a bit. In order to remove some sql queries I moved some processing from the database into python, but that could be reverted if it turns out that it does not perform great on the server. I also noticed another performance issue on the client. It seems like the browser spends a large chunk of time parsing the svg strings created by feather.replace(); calls. These could probably be cached but it seems like feather-icons is not accepting pr's at the moment.

[timobrembeck]

But it seems like feather-icons is not accepting pr's at the moment.

Thanks! I did not yet have the time to look into it in detail, but since we migrated to lucide for our preact icons, we could also do the same for the regular ones, maybe this gives us a bit more flexibility...

[ulliholtgrave]

Lucide also runs with a treeshake-approach to reduce the replacement time (e.g. see https://github.com/lucide-icons/lucide/tree/main/packages/lucide#lucide). Maybe this could also help us improve the general performance of our CMS by defining our used icons on each view.

[david-venhoff]

I added a small change which first load the trees that should get re-expanded and then the rest. This seems to improve performance quite a lot, since usually only a few sub-trees are expanded.

[david-venhoff]

I am not sure about whether our redis cache will still work now that the requests use the POST method, so this might be something to change

[timobrembeck]

I am not sure about whether our redis cache will still work now that the requests use the POST method, so this might be something to change

Do we even have request-level caching enabled? I'm not sure... And the database-level cache should work independently from the request method, right?

[david-venhoff]

Oh, I think I had a wrong understanding of the cache :see_no_evil: In that case it should be no problem :+1: