List View: Allow dragging outside the immediate area by passing down a dropZoneElement #50726
Conversation
andrewserong
added
[Type] Enhancement
|
Size Change: +22.8 kB (+2%) Total Size: 1.4 MB
ℹ️ View Unchanged
|
…a dropZoneRef from outside the list view
andrewserong
force-pushed
the
try/list-view-drop-zone-allow-passing-in-a-drop-zone-ref
branch
from
9f0599e
to
d925f68
Compare
packages/block-editor/src/components/list-view/use-list-view-drop-zone.js
Outdated
Show resolved
Hide resolved
andrewserong
requested review from
ajitbohra,
draganescu,
talldan,
noisysocks,
tellthemachines,
adamziel,
kevin940726 and
ellatrix
as code owners
|
From the GIFs this feels like a substantial improvement, and something that I've wrestled with countless times. In testing I can't get it to work, though. Testing the post editor:
What am I doing wrong? |
There was a problem hiding this comment.
Confirming what @jasmussen sees. I can't seem to trigger this change either when dragging past the last item in the list. Everything built and working correctly from what I can see?
|
Thanks folks! Sounds like I might have broken something in the latests commits, I'll dig into it 👍 |
|
Flaky tests detected in 4eb834d. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5051597076
|
|
Thanks again for testing and flagging the issue @jasmussen and @apeatling — it turns out I was testing with the I've pushed a fix in 970217e, so it should be working now, but do let me know if you still run into any issues! Updated: I've added a couple of simple tests in 84ac583 to test that the drop zone is flagged correctly. |
| // If a custom dropZoneRef is passed, use that instead of the element. | ||
| // This allows the dropzone to cover an expanded area, rather than | ||
| // be restricted to the area of the ref returned by this hook. | ||
| const element = dropZoneRef?.current ?? elem; |
There was a problem hiding this comment.
I'm wondering how this will work in terms of the cleanup of the hook.
Because it's a ref effect, I think the callback will typically only trigger when elem is unmounted, not when dropZoneRef.current is unmounted.
There was a problem hiding this comment.
Good question! I think this is working pretty well so far. To confirm I logged out element within the callback, and it appears to be the right element:
As far as I can tell the behaviour is something like the following:
- We pass in a ref to
useDropZone, butuseDropZonealso returns aref. Thatrefis still used in the list view, to attach to theTreeGridcomponent. - When
TreeGridunmounts, that results in the cleanup callback being called. - Because the cleanup callback was instantiated with a reference to
elementbeing the one passed in bydropZoneRefthe cleanup callback cleans up the passed in element. - Also, because we have
dropZoneRef?.currentin the dependencies array ofuseRefEffectwhen the passed in ref changes, the cleanup appears to correctly fire, too. From checking the docs, this appears to be consistent with how useEffect works in that the cleanup fires not only when the component unmounts, but whenever any of the dependencies change. The doc comment foruseRefEffectappears to confirm this here, too:gutenberg/packages/compose/src/hooks/use-ref-effect/index.ts
Lines 11 to 29 in 62b3b0e
So, all up, I don't think there are any stray event listeners not being removed, as far as I can tell.
Do let me know if you think I've missed anything here, though!
There was a problem hiding this comment.
When TreeGrid unmounts, that results in the cleanup callback being called.
Sorry if I'm making this more complicated. Given this is being introduced as a generic stable API, I'm mainly thinking that there could be different ways it's used (or misused):
- The
dropZoneRefcould reference a completely separate part of the DOM that isn't mounted/unmounted at the same time as the effect's component. - The
dropZoneRefcould reference a parent of the effect's component that isn't mounted/unmounted at the same time.
I don't know if there are tests that can be added to assert these different cases work as expected.
It also might be worth expanding upon the docs for the prop to ensure that the right usage of this API is promoted. There's an example of this for Popover's anchor prop that recommends particular usage - https://github.com/WordPress/gutenberg/blob/trunk/packages/components/src/popover/README.md#anchor-element--virtualelement--null.
Also, because we have dropZoneRef?.current in the dependencies array of useRefEffect when the passed in ref changes, the cleanup appears to correctly fire, too
This is the part that often trips me up. With dropZoneRef being a ref type, it won't trigger a re-render when it changes. I've sometimes opted to store an element using useState for that reason (which is also what Popover recommends).
There was a problem hiding this comment.
Sorry if I'm making this more complicated.
No apology necessary! I'm happy to go as slowly as needed with this PR — I always like to be a bit more cautious when making changes to lower-level packages such as compose, and it's important we get it right and don't introduce any issues 👍
I don't know if there are tests that can be added to assert these different cases work as expected.
Good example use cases, it's worth digging in, I'll do a little more exploration to see if it's possible to come up with additional test cases. I think expanding the test cases there is probably a good path toward building confidence around the API change.
It also might be worth expanding upon the docs for the prop to ensure that the right usage of this API is promoted. There's an example of this for Popover's anchor prop that recommends particular usage
Good idea, for some reason useDropzone isn't documented in the compose package's readme, but I'll have a go at writing an entry for it.
This is the part that often trips me up. With dropZoneRef being a ref type, it won't trigger a re-render when it changes. I've sometimes opted to store an element using useState for that reason (which is also what Popover recommends).
Ah, good point, because the ref reference itself isn't changing, only current 🤔. In practice, I haven't yet run into any issues in this PR so far. In terms of using useState, do you mean we'd do that internally within useDropZone, or are you imagining that the consumer would use useState, and we'd pass the element directly to useDropZone instead of a ref?
Edit: I think you probably mean the latter — and I can see that the url popover for example, uses the state approach here:
— happy to swap it over to that pattern here 👍There was a problem hiding this comment.
Edit: I think you probably mean the latter — and I can see that the url popover for example, uses the state approach here
Yep, exactly that 👍
There was a problem hiding this comment.
Update: I've done the following:
- Swapped out
dropZoneReffor adropZoneElementand updated usage to use state for storing the element before passing it along to theListView(and then on touseDropZone) - Added a README file for
useDropZone— because the hook is still currently exported as experimental, I couldn't add directly to thecomposepackage readme. I see a couple of other experimental hooks also include their own README files in thecomposepackage, so this seemed like a decent place to store the documentation for now, while the hook is still "experimental". Happy for any feedback there, I found it a bit challenging coming up with straightforward wording 😅
I haven't looked into exploring adding other tests just yet, but will dig in tomorrow.
Thanks again for the feedback!
There was a problem hiding this comment.
because the hook is still currently exported as experimental, I couldn't add directly to the compose package readme.
Thanks, didn't realise it was experimental. It must have been that way for ages!
My hunch is that using state to store the element will probably solve the issues, hopefully that's the case.
andrewserong
changed the title
|
Thanks for the re-reviews! @talldan and @kevin940726 — unfortunately I haven't had much luck writing additional tests for this, as I can't seem to get the event handlers to fire within an individual test (I've tried a At this stage, do you think adding more tests is a blocker to landing this PR? Happy to keep looking into it, but I'm currently a bit stumped as to how to reliably write tests for this hook where the drag events are fired 🤔 |
I don't really know a lot about the testing situation, so I'm not very useful in offering suggestions! I think it's good to merge given the docs now recommend using the hook in the same way List View uses it (and that's working well). |
Co-authored-by: Daniel Richards <daniel.richards@automattic.com>
Thanks Dan! I've just committed your Readme suggestion, and once the GH actions pass, I'll merge this in. |
andrewserong
deleted the
try/list-view-drop-zone-allow-passing-in-a-drop-zone-ref
branch
What?
Part of addressing #43881 and #32438, alternative to #49420 and #50689. Overall, this PR makes dragging to the top and bottom positions of the list view easier.
Allow dragging and dropping within the list view, beyond the bounds of the list view itself, when passed a
dropZoneElement(an element to be used as the drop zone, typically a parent of the final drop zone ref). Within the list view sidebar, pass the list view container area as adropZoneElementto theListViewcomponent.Then, when the mouse leaves that drop zone area, clear the drop target so that the blue line no longer appears. The result should be that the blue drop indicator line within the list view is now accurate — it will only display when a drop will occur, and it displays across the whole list view area, making it easier to drag to the top and bottom-most positions.
Why?
One of the frustrations with drag and drop in the list view is that it's very difficult to drag to the top and bottom-most positions. This PR hopefully makes that experience feel more flexible and accurate.
How?
dropZoneElementelement touseDropZoneand use its element if available, falling back to the one passed down byuseDropZone.ListViewanduseListViewDropZonelevels.ListView.nullso that the drop indicator disappears.Testing Instructions
trunk, it should be a lot easier to drop to these positions.Screenshots or screencast
Note how in the before version, the Heading looks like it can be dropped to the very bottom of the area by dragging well below, but it cannot. In the after version, the drop is respected correctly.
Some more details of the behaviour in this PR: