Drag and drop: Allow dragging into template parts

[andrewserong]

Part of #33683

The problem

It is currently not possible to drag a block into a template part from within the site editor. From the perspective of dragging, the template part is treated as one big block area, rather than allowing a block to be dragging within the template part.

Idea for a solution

While dragging blocks, is it possible to switch to a mode that allows the blocks within template parts to be treated the same way as blocks that live within the template (or something like that)? If a user drops a block within a template part area, the block should be dropped within that template part. If the block is dropped within the template itself, the block should be dropped within the template.

Screengrab

The following short screengrab shows that the Header area (while dragging) is treated like one big block, rather than allowing the user to drag and drop within that template part:

2023-11-16.11.06.51.mp4

To-do

• Allow dragging into template parts when dragging existing blocks
• Allow dragging into template parts when dragging files from the desktop or a block from the inserter
• Look into why the drop indicator line is offset in Playground

[talldan]

My guess when I saw this is that it's the block overlay that's preventing drag and drop. The thing that prevents clicking straight into children of the template part.

I had a quick look and it seems like there's a deliberate bit of code that disables drag and drop in blocks that have an active overlay:

gutenberg/packages/block-editor/src/components/use-block-drop-zone/index.js

Lines 153 to 168 in 272d0a9

	const isDisabled = useSelect(
	( select ) => {
	const {
	__unstableIsWithinBlockOverlay,
	__unstableHasActiveBlockOverlayActive,
	getBlockEditingMode,
	} = select( blockEditorStore );
	const blockEditingMode = getBlockEditingMode( targetRootClientId );
	return (
	blockEditingMode !== 'default' ||
	__unstableHasActiveBlockOverlayActive( targetRootClientId ) ||
	__unstableIsWithinBlockOverlay( targetRootClientId )
	);
	},
	[ targetRootClientId ]
	);

When the template part is not selected it seems to have the overlay, which can be verified using:

wp.data.select( 'core/block-editor' ).__unstableHasActiveBlockOverlayActive( templatePartClientId )

No idea how the overlay works though.

[tellthemachines]

Given the work on #56574 and the discussion on that PR strongly inclining towards locking synced patterns and template parts from being editable within a wider template, implementing drag and drop into template parts may not be viable. I was about to start exploring this but will leave it until the locking behaviour is confirmed 😅

[andrewserong]

Once we see where the locking behaviour lands, I wonder if an approach for drag and drop could be to render a visual overlay of some kind when dragging within a template part or synced pattern so that it's still possible to do, but it's clear to the user that they're dropping within a template part? Like, if once a user starts dragging, additional borders or overlays are rendered over the template part area, or something like that...

In any case, good idea to leave it for now while the discussion continues!

[tellthemachines]

I'm not sure. If a pattern is locked to editing, we should respect that. On the other hand, once users have clicked on "Edit" to allow the pattern to become editable, drag and drop should work just as well as anything else.

There's also the case of partially synced blocks, where if the block has an editable area, it should be possible to drag other blocks into it. That's still under construction though, so yeah let's see what needs to be done once it's ready!

[andrewserong]

I've started a PR to work on this over in #58423 that explores partially disabling the overlay and allowing dragging within template parts. It could likely use some design feedback to figure out whether or not it's too confusing that a user might drag next to a template part versus within it.

[andrewserong]

Re-opening this issue as #58423 solved the issue of dragging blocks that already exist within the template, but didn't factor in dragging from the inserter. Here's a quick video, kudos @annezazu for spotting this / sharing the following video:

dragging.into.template.parts.mov

In that video, a couple of issues appear to be at play:

• Dragging from the inserter means that we're not currently dragging any blocks. The logic in Drag and drop: Allow dropping within template parts #58423 only handled the case of dragging existing blocks, and not dragging a block from the inserter (or a file from the desktop)
• Playground adds some UI chrome at the top of the page, and the positioning of the drop indicator line doesn't play nicely with this — note that the drop indicator lines are a little lower in the video than they should be. I'm not sure if this needs to be resolved on the Gutenberg side or the Playground side, but ideally the drop indicator line should be aware enough of positioning to factor in any required offsets