Fix: Render Ordertab only when it is active

[Abhishek-17h]

• [x] I signed and returned the Plone Contributor Agreement, and received and accepted an invitation to join a team in the Plone GitHub organization.
• [x] I verified there aren't other open pull requests for the same change.
• [x] I followed the guidelines in Contributing to Volto.
• [x] I succesfully ran code linting checks on my changes locally.
• [x]I succesfully ran unit tests on my changes locally.
• [x] I succesfully ran acceptance tests on my changes locally.
• [ ] If needed, I added new tests for my changes.
• [ ] If needed, I added documentation for my changes, either in the Storybook or narrative documentation.
• [x] I included a change log entry in my commits.

---

The video showcases the behavior after the fix: Screencast from 2025-01-13 09-17-05.webm

Closes #6492

[netlify[bot]]

✅ Deploy Preview for plone-components canceled.

Name	Link
🔨 Latest commit	bf9b7a11a62d7e59e9660f8b5536b7a66f4dd030
🔍 Latest deploy log	https://app.netlify.com/sites/plone-components/deploys/67e2644fbe24b50008f558b9

[Abhishek-17h]

@stevepiercy @ichim-david @davisagli Please provide review.

[stevepiercy]

This is a nice step forward. Thanks for your work on this.

In the video, I noticed two things that I'd like to ask for opinions from the members of both the @plone/volto-accessibility and @plone/volto-team. Please don't make changes yet, but let's get some feedback.

1. When the Order tab gets activated, there is a slight delay of about a half-second with a "no entry" icon 🚫 displayed. Should that be changed to a "Loading" icon? When editing a page or control panel, then click Save, I see the loading class injected into the Save button and a grey spinning circular line.
2. I don't think the Order list items should unload when the Order tab gets deactivated after it was active one time. I think it should remain loaded, but hidden. That will eliminate second and subsequent reloads while editing a given page.

[Abhishek-17h]

Thank you, @stevepiercy, for your suggestions.

I completely agree with your first suggestion regarding replacing the icon 🚫 with a "Loading" icon. In fact, I had initially considered implementing this change before raising the PR but decided to keep the existing behavior to gather feedback from the Volto team and accessibility experts. It's great to see that you noticed it too, as it reinforces the need for improvement in this area.

Regarding your second suggestion, I think it’s a great idea, but I am concerned that its implementation might conflict with the main issue being addressed.

Looking forward to hearing more thoughts from the Volto team and accessibility members on these points!

[Abhishek-17h]

@ichim-david please provide review on this.

[ichim-david]

@Abhishek-17h technically speaking what you did is what I've asked.

The problem is that the UX isn't very good as it takes a long time to load even locally with a very fast MacBook pro. I made a video where I compared the before and after and mentioned a few things that I would still play with. https://www.youtube.com/watch?v=IFaCNBAGshE The TLDR is:

• we need a loading indicator as that round circle cut in half is the icon usually used to denote that the block doesn't have any block options.

See if you can introduce a loader to give some info to the user that the panel is loading. I would also try to look at the logic of the component and try to understand why it takes so long to load and if there is anything that can be done to speed it up.

If we were to simply merge this change it would be a degradation of service of the order tab for the editor on account on having to wait so long to interact with it, especially on second time interactions on the same page.

[Abhishek-17h]

@ichim-david, I have watched your testing video and truly appreciate the time you took to explain everything in detail. I will implement the things you mentioned. Thank you for your guidance!

[Abhishek-17h]

@ichim-david have a look now. Made two changes: 1)Added loader svg for order tab instead of forbidden svg and please check size of loader as I declared size which looked perfect to me. 2)Order tab now renders on first time and remain rendered .By doing this user don't have to wait every time for order tab to render and it is better than previous behaviour.

Ref Video: Screencast from 2025-01-19 19-07-13.webm

I don't think we can speed up the rendering of the order tab if we only want to render it when it's active. I've tried many things but haven't had any success. The changes that I made looks best to me than existing one. Waiting for your response.

[Abhishek-17h]

@stevepiercy give your feedback also on this.

[stevepiercy]

The animated loading icon looks much better.

There are two rendering times: (1) that which the user perceives, and (2) that which is the actual render time after the page is loaded in edit mode, and then the editor clicks the Order tab.

To reduce option 1 time, we can pre-load option 2. But that would defeat the purpose of this PR and original issue.

I have no idea how to improve option 2. Its slow render time only became apparent after work on this PR was started.

At this point, we have a trade-off between either having a quick initial Order tab experience or waiting to initially render the Order tab only when it's active. I don't see the advantage of degrading the editor experience.

@ichim-david what is the actual problem with rendering the Order tab when it is not active? Yes, it shows up in Developer Tools, but why is that a bad thing?

[sneridagh]

@ichim-david honestly, do you think that this is the way of fixing this one, or we should look into a much deeper fix, fixing the updates on components as we talked some time ago? Maybe we should also put @robgietema in the loop.

[ichim-david]

@ichim-david honestly, do you think that this is the way of fixing this one, or we should look into a much deeper fix, fixing the updates on components as we talked some time ago? Maybe we should also put @robgietema in the loop.

The animated loading icon looks much better.

There are two rendering times: (1) that which the user perceives, and (2) that which is the actual render time after the page is loaded in edit mode, and then the editor clicks the Order tab.

To reduce option 1 time, we can pre-load option 2. But that would defeat the purpose of this PR and original issue.

I have no idea how to improve option 2. Its slow render time only became apparent after work on this PR was started.

At this point, we have a trade-off between either having a quick initial Order tab experience or waiting to initially render the Order tab only when it's active. I don't see the advantage of degrading the editor experience.

@ichim-david what is the actual problem with rendering the Order tab when it is not active? Yes, it shows up in Developer Tools, but why is that a bad thing?

@stevepiercy The problem is that we render another set of drag and drop block clones which re-render on any of the block changes. And this is happening even when the order tab isn't focused and in a page with many blocks and with many text editors it can introduce a performance problem since you start typing and for each character, all of the blocks are re-rendered. Once in the main area and the second time in the order tab area.

If we have the order tab rendered only when we actually interact with it, and then we drag and drop the blocks We avoid this extra performance overhead.

@sneridagh Since it's not an easy thing to fix I think having the order block rendered only when we interact with it is a good workaround until we are able to make both the inline area and the order area less reactive to a block change which re-renders all of the blocks since it's part of the same drag and drop area.

I would also add a setting in the config enabled by default to render the order allowing this feature to also be turned off if someone doesn't want it.

[stevepiercy]

@ichim-david thanks for the explanation. I'm surprised to learn that the Order items render for every keystroke while editing inside a block, and not only when drag-and-dropping. I assumed it happened only when drag-and-dropping. Is there a purpose for rendering on every keystroke?

I also like your suggestion of making it a configurable setting that editors may opt-in to, perhaps explaining the trade-off, until we can optimize the render function. We should explain the trade-offs in the setting UI, of course, and name it well.

[ichim-david]

@stevepiercy have a look at this video, I started without audio but after the 1 min mark I also started saying something. This makes it even more obvious why I am insisting on rendering this order tab only when it's focused.

https://github.com/user-attachments/assets/e367ee31-ddfb-4fdb-988b-c00810bd2885

[robgietema]

LGTM

[sneridagh]

@plone/volto-team Can I have a final look and nod for this one, please? Thanks!

@ichim-david @stevepiercy all settled on this one?

[stevepiercy]

@ichim-david @stevepiercy all settled on this one?

I'm OK with it, provided @ichim-david is satisfied, and we create a new issue to capture the future improvements, if y'all agree, specifically:

• Make both the inline area and the order area less reactive to a block change, which re-renders all of the blocks since it's part of the same drag and drop area.
• Add a setting in the configuration enabled by default to render the order, allowing this feature to be turned off if someone doesn't want it.
• Document both the above.

[Abhishek-17h]

@pnicolli You are right , and I done the same when I raise this PR but it takes so much time to render order tab even though activeIndex==2 mentioned in this video. That's why I introduced a state variable which tracks activeIndex and ensure that order tab remains rendered after initial load.

The video showcases the behavior after the fix: Screencast from 2025-01-13 09-17-05.webm

New behaviour is mentioned in this video

Ref Video: Screencast from 2025-01-19 19-07-13.webm

[ichim-david]

I'm going to check this again today

[sneridagh]

@Abhishek-17h I tried this out, and I think that the perceived performance has not improved much... Could someone else confirm?

[Abhishek-17h]

@Abhishek-17h I tried this out, and I think that the perceived performance has not improved much... Could someone else confirm?

@sneridagh I believe this approach could be a better solution if the Order tab rendered more quickly. Since that's not happening, we may need to consider a deeper fix. I will try for it and If you have any suggestions or tips for how can I approach this , please provide as u mentioned here.

@ichim-david honestly, do you think that this is the way of fixing this one, or we should look into a much deeper fix, fixing the updates on components as we talked some time ago? Maybe we should also put @robgietema in the loop.

Till then let this PR remain as it is.

[github-actions[bot]]

Hi There! 👋

We haven't seen any activity on this pull request in a while :sleeping:, and we want to make sure that it's still relevant. Please let us know by:

• adding a comment about what needs to be done next 💬
• updating its status and other labels 🏷️

Otherwise close this pull request. 🧹