fix: proper collapsing of long element #5694
Conversation
|
✔️ [V2] 🔨 Explore the source changes: 2a6f968 🔍 Inspect the deploy log: https://app.netlify.com/sites/docusaurus-2/deploys/6169792ef021490008760d3f 😎 Browse the preview: https://deploy-preview-5694--docusaurus-2.netlify.app |
|
⚡️ Lighthouse report for the changes in this PR:
Lighthouse ran on https://deploy-preview-5694--docusaurus-2.netlify.app/ |
|
Size Change: +4.46 kB (+1%) Total Size: 841 kB
ℹ️ View Unchanged
|
|
Hey I'm not sure to understand how to reproduce or test this fixed the Redux doc issue.
Redux is not using beta.6/canary, can this be reproduced with latest? What I see is that the scrollbar is covered by some white rectangle, so this doesn't seem related to the collapsible component to me. This seems related to the announcement bar CSS var, disabling this CSS fixed the problem:
|
|
I can reproduce it on the latest version, here on another site https://docs.tuist.io/tutorial/get-started/
|
|
Related to #5254? Would that be properly fixed... or is it only fixable with |
|
Oh yes those are 2 distinct issues. Yes @Josh-Cena is right this is related to the sidebar item width decreasing when the scrollbar appears, when items wrap on 2 lines. The collapsible height computation is probably done before the scrollbar appears. If we used a label that wraps/unwraps on Docusaurus docs test instance, we could see in the preview if current code fixes the issue. Example label on Tuist: |
There was a problem hiding this comment.
It seems to reintroduce issues with the mobile collapsible TOC that the referenced PR did solve (it works better in prod than in the deploy preview when clicking fast in it)
Also I'm not sure it solves the Redux issue without testing it locally: can you add sidebar config in Docs test instance so that we can see it fixes it?
| items: [ | ||
| ...generateHugeSidebarItems(4), | ||
| ...[ | ||
| { | ||
| type: 'link', | ||
| href: '/', | ||
| label: 'Test Test test test test test test', | ||
| }, | ||
| ], | ||
| ], |
There was a problem hiding this comment.
Why ... instead of just adding the item at the beginning?
Also I'd suggest adding that example at the very beginning. Adding it at the end makes it not clear that it actually wraps, because we don't see it moving from 1 line to 2 lines (at least on my screen). I had to remove the scrollbar with devtools to be sure it does.
There was a problem hiding this comment.
Sorry, it didn't seem to matter to me, but I moved it to top of list.
reintroduces an annoying behavior
Yes, but it still not as annoying as the current issue. I still can't find better solution.
There was a problem hiding this comment.
The wrapping affects only a few sites (it's worst but unless bad luck the last item remains clickable).
The collapsible problem is a smaller problem but it affects all sites in multiple places.
I'd rather wait and find a better solution.
IMHO the solution we want is to ensure the category label does not wrap anymore: #5254 It would solve 2 issues at once
There was a problem hiding this comment.
I disagree, the current issue affects to more sites (not just those two sites) and therefore more serious. The other issue with multiple clicks is a rare case, though. Well then let's initially calculate collapsible element height with possible scrollbar. Any objections?
There was a problem hiding this comment.
I think we won't agree on this, unfortunately, but I don't like the idea to fix an issue (that none or very few users reported as a major problem) by introducing a regression somewhere else: we must find a way to fix both issues at once.
This new solution is not ideal either.
A scrollbar can temporarily appear as you click:
And if you reduce the size of the category that has a wrapping element, you'll notice some extra height added at the end, and then "fixed" on animation end.
There was a problem hiding this comment.
I think you should consider realistic usage scenarios first. So the scrollbar will not be displayed if the user clicks once -- this is main realistic use case. Why would anyone want to click on a category many many times?
"no user reported" -- that's because users mostly don't care on it, they came to docs site for information, they are not testers. Better ask the owner of Redux site about this issue, he's hardly aware of it because he doesn't test the whole site by clicking on every category, I guess.
|
👍 we agreed on the first proposed solution, temporarily |
Motivation
There seems to be a regression after #5146
At least probably on sidebar items with large children the collapsing transition does not complete correctly.
You can see this now on the Redux site if you click on "Using Redux" in sidebar. https://redux.js.org/introduction/getting-started
This is due to the fact that initially scrollable element height via
scrollHeightis not calculated correctly withoverflow:hidden. I don't really understand why this happens on some elements. For example, on the Docusaurus site this bug doesn't reproduce (https://docusaurus.io/tests/docs)So in order to get a consistent behavior, we don't need to check collapsible element height after completing transition. However, considering that in #5146 we introduced extra
requestAnimationFramecall, this will still mitigate issue with multiple clicks.Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Try to apply this patch to Redux site locally.
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/facebook/docusaurus, and link to your PR here.)