[WIP] List View: Allow dropping a block by dragging outside the vertical area of the list view #49420
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ea of the list view
andrewserong
added
[Type] Enhancement
|
Size Change: +177 B (0%) Total Size: 1.34 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in a054fe1. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4550759358
|
|
Thanks for working on this as it's a problem that really needs solving. I'm not sure about this solution, as it seems to require some math hacks, and I don't think it's going to work in all situations (like if there's another UI above or below List View, like there very likely will be in browse mode.) The same bug exists in the editor canvas too (as well as parent blocks like 'Media and Text'), and the code there is really similar to List View. So I think it'd be good to explore if there's any way to solve the problem in both places. Having said that, if it can be solved only in List View, that's ok too, as improving the user experience is what's paramount. I think the core of the problem is function ListView() {
// dropZoneRef can only be used within ListView.
const { ref: dropZoneRef, target: blockDropTarget } = useListViewDropZone(); An alternative to this PR (and quite a simple fix) is to move const { ref: dropZoneRef, target: blockDropTarget } = useListViewDropZone();
<div className="edit-post-editor__list-view-panel-content" ref={ dropZoneRef }>
<ListView dropTarget={ blockDropTarget } />
</div>I think it would work, though it is a bit unusual passing Another option is to refactor function ListView( { dropZone } ) {
// dropZoneRef can only be used within ListView.
const { target: blockDropTarget } = useListViewDropZone( { dropZone } ); That would be a lot of work, but I think it would potentially provide the solution for the editor canvas too. |
|
Thanks for the feedback @talldan, that's super helpful! I prefer the idea of lifting up where the One thing that I thought might be worthwhile attempting to tackle first, though, is the issue of dragging to all levels of the block hierarchy: #33678. I know that one likely won't be simple, but once we extend the area where folks can drag at the very bottom of the list, I think it'll become very apparent that in expanded nested blocks, you can't actually drag to the actual bottom of the list. So it might be worth seeing if we can come up with a solution for that first. Again, I'm having fun digging into these granular list view tasks, so happy to try digging in there, too! |
Agree, that definitely seems like the easiest and most sensible option.
Yep, adding breathing room might be an easy solution, if design folks are happy with that.
Glad you're enjoying it! I don't have many ideas on how to solve #33678, so it'll be interesting to see what you can come up with. |
25 tasks
This was referenced May 17, 2023
Closed
|
Closing out this PR now, as I think I have a decent version working over in #50726, which allows passing a ref to |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
🚧 🚧 🚧 WIP: This is still experimental for the moment 🚧 🚧 🚧
Part of addressing issues including #43881 and #32438
Allow a user to more easily drag a block to the top-most or bottom-most positions.
This PR explores seeing if we can allow a drop event to occur for the list view when a block is dragged outside the list view area, but is still within its horizontal position. Note: this PR does not address the issue where you cannot drag a block to be beneath a non-collapsed Group block. For dragging beneath a collapsed Group block there is a potential fix open over in #49390
Why?
Currently it is very difficult to drag a block to the top-most or bottom-most positions in the list view. To do so, you need to drop the block just inside either the top block, or the bottom block, otherwise the drop event will not fire.
How?
dragendevent, and construct a fake drop event to fire if thedragendevent fires within the horizontal area of the list view (determined by the width of the last block that was hovered over).event.dataTransfer.dropEffectis set and is not'none'so that a user who pressesEscapeto cancel the drag event does not accidentally cause the drop event to fire.To-do
Testing Instructions
Play around with the list view, dragging blocks to the top-most or bottom-most positions. It should be easier to do now, as dragging anywhere in the vertical plane should respect the position indicated by the blue popover indicator line.
Screenshots or screencast
2023-03-29.16.57.33.mp4