-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
List View: Allow dragging underneath collapsed non-empty container blocks #49390
List View: Allow dragging underneath collapsed non-empty container blocks #49390
Conversation
Size Change: +26 B (0%) Total Size: 1.34 MB
ℹ️ View Unchanged
|
Flaky tests detected in 8614fbc. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4548990995
|
OH YES! This is such a better experience. Thank you! GIF showing much clearer dragging: This feels intuitive enough. While you're here, but completely fine to keep separate if you prefer, can you explore using a thicker drop indicator than 1px? Be nice to try 4px and rounded edges like this (without the plus): but if 1.5px or 2px works better, plus the radius, that would still feel more substantial. Thanks Andrew! |
Thanks for reviewing @jasmussen!
Absolutely — I have a few ideas for further little list view improvement PRs, so I'll explore this idea in a separate one. For the moment, because there are quite a few distinct issues with the drag behaviour, I'm trying to focus on very granular PRs that just look at one thing at a time. My hope is that in this way we can chip away at the bigger problem of "dragging in the list view feels difficult and flaky", and also have a good record of each of the individual changes in case they need to be revisited in the future. Thanks again for the quick review, I'll continue pinging you on subsequent PRs 😀 |
What?
Fixes: #46678
This is a very small granular PR just looking at one part of drag and drop behaviour in the List View.
The goal in this PR is to allow blocks to be dragged underneath a container block that has children and is collapsed. On
trunk
, when hovering over the bottom half of a collapsed group block, it would always nest the dragged block into the group, rather than allowing you to slot it in underneath.Why?
When rearranging blocks, it can be frustrating if you want to place something underneath a collapsed group, but it accidentally winds up being nested instead. Also, if your list of blocks contains mostly collapsed groups, prior to this PR, it was very difficult to rearrange blocks. This is fairly common in site templates.
How?
data-expanded
to the row for the block (this is intentionally separate fromaria-expanded
so that passing the data along isn't dependent on how the expanded state is expressed for accessibility)useListViewDropZone
and togetListViewDropTarget
— then, only add blocks as children if the nesting gesture is in use (hovering over the right-hand side of the block), or the block that has children is expanded.A caveat: Note that dragging a block beneath the bottom-most block in the List View is still very difficult to do due to the size of the drop zones. This has not been addressed in this PR. Also not addressed: when the container block is expanded and at the bottom of the list, you cannot drag a block to be beneath it. I'll have a go at tackling those things in follow-ups.
Testing Instructions
Screenshots or screencast
One of the benefits of this PR is that it makes it possible to drag a block beneath the bottom block when the bottom block is a container block. In the site editor, this means that you can more easily re-arrange the footer:
Note: it is still difficult to move blocks to the bottom-most position as the dropzone there is very small. I'll look at addressing that separately to this PR.