[PUI] LoadingOverlay preventing user actions on heavy loading

[LavissaWoW]

Please verify that this bug has NOT been raised before.

• [X] I checked and didn't find a similar issue

Describe the bug*

Well, bug is a general wording here. It's more of a consequence of the LoadingOverlay

Thing is, when loading a site that is fetching a heavy API call, you'll be locked out of the whole UI while it's loading. Accessing something that makes a top-level API call that takes time will render you unable to stop waiting.

Steps to Reproduce

1. Set up an InvenTree instance with the demo dataset
2. Go to Parts
3. Watch the overlay hang for several seconds and be unable to perform any actions

Expected behaviour

Going in a reactive direction, I'd love to move the LoadingOverlay down to individual panels, components etc using Skeleton components to render while our initial request is processing. Locking the user out of being able to perform actions because the site is waiting is not a good impression.

Deployment Method

• [ ] Docker
• [ ] Bare metal

Version Information

InvenTree-Version: 0.14.0 dev Django Version: 3.2.23 Commit Hash: 0126613 Commit Date: 2024-01-23 Commit Branch: details-panel Database: sqlite3 Debug-Mode: True Deployed using Docker: True Platform: Linux-5.15.133.1-microsoft-standard-WSL2-x86_64-with Installer: DOC nullActive plugins: [{"name":"InvenTreeBarcode","slug":"inventreebarcode","version":"2.0.0"},{"name":"InvenTreeCoreNotificationsPlugin","slug":"inventreecorenotificationsplugin","version":"1.0.0"},{"name":"InvenTreeCurrencyExchange","slug":"inventreecurrencyexchange","version":"1.0.0"},{"name":"InvenTreeLabel","slug":"inventreelabel","version":"1.0.0"},{"name":"InvenTreeLabelSheet","slug":"inventreelabelsheet","version":"1.0.0"},{"name":"DigiKeyPlugin","slug":"digikeyplugin","version":"1.0.0"},{"name":"LCSCPlugin","slug":"lcscplugin","version":"1.0.0"},{"name":"MouserPlugin","slug":"mouserplugin","version":"1.0.0"},{"name":"TMEPlugin","slug":"tmeplugin","version":"1.0.0"}]

Please verify if you can reproduce this bug on the demo site.

• [ ] I can reproduce this bug on the demo site.

Relevant log output

No response

[LavissaWoW]

I'm willing to give this a thorough rewrite when my current PR is done. And by that, I mean moving away from the LoadingOverlay and into Suspense-based loading where it makes sense.

[SchrodingersGat]

@LavissaWoW I am not seeing such delays on my setup. Are you running off the latest code? There was a bug specific to the /parts/ page which queried all parts from the server - this has recently been fixed

[SchrodingersGat]

Nevertheless, a "global" loading overlay is obviously not good - although I have not observed this. If you can point out the issue (or submit a patch) I agree that this is not a good way to go

[LavissaWoW]

Might be that I haven't pulled that fix into my working branch atm. But I suppose my vision kinda still stands. Generating skeleton UIs is something that greatly improves user experience, as they feel "something" is happening even tho everything is loading still. Setting up Skeleton components to render while its chilren resolve will help give the whole site a much better feeling of responsiveness (Even though it adds some ms of latency to loading)

[matmair]

I'd probably favour adressing the long running API-calls rather than building UI elements that should not bee seen more than a few eye blinks but if it is something you want to spend time on why not.

[LavissaWoW]

Fair point. However, this is a recording of just hitting F5 locally.

No Strict mode, no refetchonmount. You clearly see something load, then the whole page going into LoadingOverlay again. I don't think fixing this will be a major timesink tho, as it's all about defining Skeletons where they need to be, and have them react to the proper requests.

But all in due time. I just wanted to put it out there that I kinda wanna address this :)

[matmair]

You are very welcome to invest time into this, I find cosmetics very secondary with most of the functional UI still missing

[LavissaWoW]

That is true. The original intent with the issue was the blocking of user actions, but I'm not seeing it after pulling in master to my working branch. I'm happy to alter the issue to reflect a future commitment to make the site more reactive :)

[SchrodingersGat]

Based on your video above (which I appreciate is no longer the case) - that sort of UI blocking is not what we want, so I am happy to accept a PR to provide a better mechanism.