Add drag and drop to List View in Navigation Screen #23952
Conversation
talldan
added
[Type] Technical Prototype
packages/block-editor/src/components/block-navigation/use-block-navigation-drop-zone.js
Outdated
Show resolved
Hide resolved
|
Size Change: +5.27 kB (0%) Total Size: 1.17 MB
ℹ️ View Unchanged
|
|
Haven't had much time to progress this lately, but thought I'd leave a progress update: Remaining tasks are:
|
talldan
force-pushed
the
add/drag-and-drop-to-block-navigation
branch
from
d93011b
to
7218df6
Compare
|
I posted some designs for drag-and-drop in this issue: #24029 (comment) |
|
Thanks @shaunandrews, the designs look great and are really helpful! One thing that would be good to clarify is how we determine when the user intends to nest a block block, versus when they'd like to drop before or after a block. I had a look at how Figma handles this in its layers panel, and it seems like they subdivide a single Group into three drop zones, the top part for dropping before, the middle part for nesting, and the bottom part for dropping after: In this PR currently, I've done it slightly differently. If the cursor is positioned on the left side of the block the block is dropped before/after, while to the right side of a block will result in the block being nested: |
talldan
changed the title
|
I had a quick run with this PR an I have to say it works pretty well! Great work here! This will be so useful outside of the editor as well. 🎉 |
|
This is really really good. I only noticed a few quirks:
I forget: did we plan on having Nest and Un-nest buttons in the More options dropdown? |
|
Thanks for the testing!
I'll need to double-check what's happening. There is a Having said that, this is how it works in the normal editor, so I don't think it's an issue if it can't be made to work.
Yep, this is something tricky to get right. You shouldn't have to move the mouse that far to the right, but you do need to be over the block you intend to nest into (in the bottom right quadrant), it looks like your mouse was over the block below for part of the drag. That could be something to do differently. What do you think about the comment here - #23952 (comment), would it be better replicating the way Figma handles this?
Yep, this is still TODO. Not entirely sure the best way to achieve this at the moment. |
Hm, I think I prefer the way you did it here where hovering to the right is what indicates nesting. Only I wish it accepted hovering to the right of the insertion point as well as hovering to the right of the menu item. |
talldan
force-pushed
the
add/drag-and-drop-to-block-navigation
branch
from
6f3bfbb
to
c0e9167
Compare
|
@noisysocks I've now fixed issues 1 & 2 here (#23952 (comment)). The third issue is a little more complex, looking into it next. I also noticed dragging and dropping files doesn't seem to be working, so will debug and fix that. |
talldan
force-pushed
the
add/drag-and-drop-to-block-navigation
branch
2 times, most recently
from
199826c
to
065ea1e
Compare
talldan
force-pushed
the
add/drag-and-drop-to-block-navigation
branch
from
065ea1e
to
0efea14
Compare
|
@draganescu That might be best. I'd be pretty keen to follow up by working on #22113 and bring the feature back (along with the movers, more menu and appender). edit: Now done using the existing __experimentalFeatures flag. |
This reverts commit 2bc3dbb.
|
Got this working. Works well. Its kind of interesting that I can drag from the List View and then drop on the canvas and it works. |
ZebulanStanphill
added
the
Needs Accessibility Feedback
| : true, | ||
| }; | ||
| } ); | ||
| }, [ hasPosition ] ); |
There was a problem hiding this comment.
I think even with useEffect, we still can't re-trigger the effect when ref changed? 🤔
There was a problem hiding this comment.
Opened #24914 to enable the eslint rules to help us catch these kinds of issues.
There was a problem hiding this comment.
I am definitely making an assumption that the DOM won't change during a drag/drop based on the fact that the user can't really manipulate the UI in any other way when dragging.
But at the same time, the dependency list for a hook isn't capable of handling this situation, because part of the subtree of the DOM element captured by ref could mutate, but the reference for the root element may still be the same.
For absolute correctness, a MutationObserver would probably be the best option here.
There was a problem hiding this comment.
IMHO, we can make such assumption, my suggestion is more towards code smell rather than correctness. In case when we did change the DOM in the future. Hence, I don't think we should use MutationObserver at this point :)
talldan
changed the title
|
I got to say I looked at the examples @noisysocks Robert shared here #23952 (comment) , |
|
Thanks @paaljoachim. There's a PR here that unlocks some of the features in List View that were only in the navigation screen before - #25034. It's still very early on. Also, if drag and drop seems a bit laggy in List View, there's some optimizations I've been working on in #25069. |
|
"Will the same method also be added to the List view in the regular Gutenberg screen?" Oh yes! Pleeease! |
Description
Addresses #22297
This PR is a work in progress technical prototype for drag and drop in Block Navigation. It's main purpose is for helping me explore how the feature can be achieved technically and collaborate on the changes. Once I'm happy with the approach I'll start extracting some of the changes into smaller PRs.
How has this been tested?
It's best to test this in the Experimental Navigation page, which has a persistent block navigation area.