Use the breadcrumb as the draggable handle #8764

oandregal · 2018-08-09T11:10:30Z

This PR aims to address #7114

It introduces a new withDraggable component that decouples the drag handle (in this example, the breadcrumb/hover label) from the element being dragged (in this example, the block). Unlike the existing Draggable component, withDraggable is not concerned with creating a DOM node that serves as drag handle; it's the wrapped component responsibility to do so, which makes withDraggable reusable in several use cases.

An example of how to use it:

wrap the drag handle.
initialize it with the initDragging prop exposed by the withDraggable HOC with the DOM id of the element to drag and the necessary transfer data.

import { Dashicon, Panel, PanelBody, withDraggable } from '@wordpress/components';

const MyDraggable = ( { onDragStart } ) => (
  <div id="draggable-panel">
    <Panel header="Draggable panel" >
      <PanelBody>
        <Dashicon
          icon="move"
          draggable="true"
          onDragStart={ initDragging( 
              "draggable-panel",
              { /* data to be transfered goes here */ }
          ) }
      />
      </PanelBody>
    </Panel>
  </div>
);

export default withDraggable( MyDraggable );

Current status / Open questions

For the breadcrumb to be able to handle the drag events, it needs to be visible when is clicked (now it's only visible on hover). The current status is that is always visible when the block is selected. A potential alternative is to make it visible on hover + when it is the target of a click event.

The classic block is a bit different. It doesn't show the breadcrumb. We either need an alternative handle for that (the toolbar itself?) or make it visible. This PR makes the breadcrumb visible on the classic block, just for demonstrating how bad that would be. Due to how that block behaves (it shows always a toolbar than it's converted to a mce editor on the click event) we would need to some refactorings before we are able to use the withDraggable component in that particular case:

TODO

Improve the breadcrumb draggable indicator (now it's using a hack on the compiled dashicon component).
Add back a placeholder in the block that is being dragged. Because the handle is no longer overlapped with the block content, we need a replacement for this (we used to make the draggable area visible as a placeholder when detecting that it was being dragged).
Make the breadcrumb and the draggable component areas equal. At the moment they're separated entities, use the draggable to wrap the breadcrumb. If we keep them separated, we could render the breadcrumb text also in the draggable component, to make the area equal.
~~Separate the drag handler from the logic to add a drag image and setting the drag data.~~
~~Adjust z-index to prevent the breadcrumb from showing on top of popovers.~~

Test

Drag and drop a block and test that it works as used to be. Specifically test: embeds (or anything with iframes), nested blocks.

oandregal · 2018-08-09T11:24:54Z

Current status:

oandregal · 2018-08-09T16:14:58Z

Status after c5e55f8:

ZebulanStanphill · 2018-08-09T17:28:41Z

I would like it if the block controls doubled as drag handles. That would provide a way to drag the selected block.

Noting that the outcome of #6224 may make this redundant and remove the need for it, but until then, I think this is a good improvement over master. I really dislike the current invisible drag handles.

oandregal · 2018-08-10T09:29:34Z

a9dc4ae implements a proof of concept for the draggable indicator using dashicons

oandregal · 2018-08-13T15:59:46Z

In fbd9d0d we experiment with the block's opacity to communicate what is being dragged instead of showing a grey box on top of the block. This approach is nicer, and also solves some technical challenges of the refactoring (see commit's comment).

oandregal · 2018-08-17T10:27:28Z

packages/components/src/dashicon/index.js

@@ -15,12 +15,13 @@ export default class Dashicon extends Component {
 		return (
 			this.props.icon !== nextProps.icon ||
 			this.props.size !== nextProps.size ||
+			this.props.viewBox !== nextProps.viewBox ||


These changes to the dashicon component is an interim hack. We need to either port them to upstream dashicon repo if they make sense or figure out a different approach to show the drag affordance to the user.

oandregal · 2018-08-17T10:30:51Z

packages/editor/src/components/block-list/style.scss

@@ -985,6 +908,10 @@
 		.editor-block-list__block:hover & {
 			@include fade_in(0.1s);
 		}
+
+		.editor-block-list__breadcrumb-drag-handle {


This is part of the dashicon hack to show a drag affordance to user. See https://github.com/WordPress/gutenberg/pull/8764/files#r210868679

oandregal · 2018-08-17T10:34:49Z

packages/editor/src/components/block-list/style.scss

@@ -95,7 +24,7 @@
 .editor-block-list__block {
 	&.is-hidden *,
 	&.is-hidden > * {
-		visibility: hidden;


Previous to this PR, the block's contents were hidden and a grey box was made visible on top of them instead. That grey box was a div element created by the Draggable and BlockDraggable components. If we want to keep that pattern we'll need to figure out something for this as we no longer have a separate DOM component as the drag handle.

Lowering the opacity of the content being dragged is also a nice pattern other apps use and helps in identifying what's being dragged.

So we don't need these.

The drag handle no longer overlaps the block content div, so we can't render a placeholder in the handle itself. We need to figure somethingelse out.

This tweaks the dashicon viewBox to render a not too embarrasing draggable indicator. This needs fixing.

Previous to this refactor, it used to be a div inside the block wrapper that would become visible when the block was being dragged. That div would appear as grey. By refactoring the drag handler to the breadcrumb we no longer have that div, so we seek to use a different technique to communicate the same behavior. I also think is nicer to show the original content.

…able

it's only used internally by the block-list component.

The new name clarifies the purpose and allows the original component to have passed the onDragStart property by some parent component.

oandregal · 2018-08-20T12:23:24Z

edit-post/assets/stylesheets/_z-index.scss

@@ -9,7 +9,7 @@ $z-layers: (
 	".editor-block-list__block {core/image aligned left or right}": 20,
 	".editor-block-list__block {core/image aligned wide or fullwide}": 20,
 	".freeform-toolbar": 10,
-	".editor-block-list__breadcrumb": 1,
+	".editor-block-list__breadcrumb": 1000000000, // used as a drag handler, we want it to be shown above the entire UI


Adjust this number to avoid conflicts with popovers:

And with the classic block:

9999a4f fixes the problem with the popover.

oandregal · 2018-08-20T12:27:57Z

packages/editor/src/components/block-list/block.js

@@ -394,7 +393,7 @@ export class BlockListBlock extends Component {
 		// We render block movers and block settings to keep them tabbale even if hidden
 		const shouldRenderMovers = ( isSelected || hoverArea === 'left' ) && ! showEmptyBlockSideInserter && ! isMultiSelecting && ! isPartOfMultiSelection && ! isTypingWithinBlock;
 		const shouldRenderBlockSettings = ( isSelected || hoverArea === 'right' ) && ! isMultiSelecting && ! isPartOfMultiSelection;
-		const shouldShowBreadcrumb = isHovered && ! isEmptyDefaultBlock;
+		const shouldShowBreadcrumb = ( isSelected || isHovered ) && ! isEmptyDefaultBlock;


This makes the hover label to stick when the block receives a click, and making it visible when a block is being edited:

I think this is a bad idea. Nothing should ever constantly overlap the content of the selected block. It is bad enough that sibling inserters currently do this; see #8206, #8881, and #8883.

If the hover label was shown outside of the block border, then I think this would be fine. Of course, that would conflict with the toolbar. I think that dragging a selected block should be done from empty space in the toolbar (or just dragging from anywhere in the toolbar, similar to what GNOME does), and/or dragging from the up/down movers on the side.

See also:

Display block tools underneath the block, instead of to the sides #6224

Do not show block movement controls unless cursor first moves into corresponding block. #8880

Move the blocks "More" button (ellipsis) to the toolbar #9074

Allow toolbar segments to collapse (responsive toolbar) #9075

This PR is at a point where it's functional and needs design review, that's indeed one of the things we need to discuss and iterate on. I've pinged @jasmussen for that.

Just want to note I'm also pretty uncomfortable with the handle being visible when the block is selected. Feels like additional weight in the UI.

oandregal · 2018-08-21T12:18:57Z

@jasmussen would love your feedback on the open questions, design/interaction wise. #9074 may be potentially related (I commented there as well).

@youknowriad @aduth I saw you were the Gutenberg core reviewers in #4115, the PR that first implemented drag and drop. I would appreciate any thoughts you may have on this PR's direction and the withDraggable HOC.

oandregal · 2018-08-21T12:23:40Z

packages/components/src/higher-order/with-draggable/index.js

+const cloneHeightTransformationBreakpoint = 700;
+const clonePadding = 20;
+
+const withDraggable = createHigherOrderComponent(


FWIW, this component ports the existing Draggable functionality (set data transfer and create a drag image).

ZebulanStanphill · 2018-08-21T15:53:03Z

Noting that #9197 is related as it affects the hover label.

jasmussen · 2018-08-22T07:19:28Z

Nice work! Thank you for working on this.

Here's a GIF, that's always helpful:

The good:

This is working well
It's completely fine to just have one spot for dragondrop

What we need to work out:

We can't have the hover label keep showing as the block is selected.
Because we can't have that, the dragondrop feature might appear to only work when you have no blocks selected.
There seems to be TWO spots to drop the block in between all blocks, not just one. Not sure why this is.

I'm personally of the opinion that drag and drop is very nice for a few things, like reordering items in a ToDo list, but for larger operations it's super fiddly and prone to error. For that specific reason I'm personally totally fine with drag and drop being purely a power-user feature that isn't made particularly visible by drag handles or affordances when a block is selected.

But the hover/select issue is nonetheless something to think about. Flagging @karmatosed and @mtias for thougths here. Should we make the up/down movers double as dragondrop handles? Are there other solutions?

oandregal · 2018-08-22T07:35:26Z

There seems to be TWO spots to drop the block in between all blocks, not just one. Not sure why this is.

This is the existing behavior on Gutenberg master as well. The reason is: the drop behavior is part of the block logic. And because you can drop a block above or below any other existing one, when you are dropping between blocks you'll have two spots: the below drop spot of one block, and the above drop spot of the next one.

Edit: there is a potential fix that keeps the logic at the block level. We'd need to modify the drop zone behavior to only offer the spot below the block by default. It'd show the spot on top of the block if it is the first one (I assume we can know this by the block order prop).

jasmussen · 2018-08-22T07:50:09Z

Ah, thanks for clarifying. This seems worth it for us to fix separately. But yes definitely out of scope for this PR.

ZebulanStanphill · 2018-08-22T14:26:29Z

@jasmussen

Should we make the up/down movers double as dragondrop handles? Are there other solutions?

I am definitely in favor of making the up/down movers double as drag-and-drop handles. The block toolbar could also double as a drag handle. GNOME does this with its header bars and I think it works quite well.

oandregal · 2018-08-27T15:46:58Z

Closing this in favor of a more step-by-step process. The first step is to refactor how drag-n-drop works internally without changing the external behavior, see #9311

When that PR lands we can discuss in a separate PR what element(s) should become the new drag handle(s). That also buy us some time to fix some existing drop behaviors in parallel, and explore/consolidate changes to UI that are being discussed in other PRs (and affect to dnd behavior).

oandregal self-assigned this Aug 9, 2018

oandregal added the [Status] In Progress Tracking issues with work in progress label Aug 9, 2018

oandregal changed the title ~~Update/dnd handle~~ Change the draggable handle Aug 9, 2018

oandregal changed the title ~~Change the draggable handle~~ Use the breadcrumb as the draggable handle Aug 9, 2018

oandregal force-pushed the update/dnd-handle branch from 9a06f5d to c5e55f8 Compare August 9, 2018 16:11

oandregal force-pushed the update/dnd-handle branch from c5e55f8 to a9dc4ae Compare August 10, 2018 09:28

ZebulanStanphill mentioned this pull request Aug 12, 2018

Drag and drop modal box or UX improvement to more easily re-order blocks or put blocks into columns #8884

Closed

oandregal force-pushed the update/dnd-handle branch from a9dc4ae to fbd9d0d Compare August 13, 2018 15:57

oandregal commented Aug 17, 2018

View reviewed changes

oandregal added 14 commits August 20, 2018 12:16

Debug: colors are fun!

add68b9

Debug: make the draggable area visible

d4f6fa7

We're going to get rid of side grabs

d06670f

So we don't need these.

Match breadcrumb positioning

c119acb

Position the handle in the top right corner, alongside the label

32a465f

Expose the handle, hide the contents

97f17ea

Dont make the handle ever visible.

9c694b6

The drag handle no longer overlaps the block content div, so we can't render a placeholder in the handle itself. We need to figure somethingelse out.

Add grab affordance

123d37b

HACK: PoC to improve the draggable indicator

a37bcde

This tweaks the dashicon viewBox to render a not too embarrasing draggable indicator. This needs fixing.

Create withDraggable HOC

ebfe05a

Refactor breadcrumb to use withDraggable HOC

ca3dbf6

Deprecate wp.components.Draggable in favor of wp.components.withDragg…

4cea178

…able

fixup docs

47f02fe

oandregal added 5 commits August 20, 2018 12:16

Remove block-draggable

74d1b9c

it's only used internally by the block-list component.

Add comment to z-index value

77f7ef1

Make cursor affordance visible

26ca9bf

withDraggable injects initDragging instead of onDragStart

ac43bb3

The new name clarifies the purpose and allows the original component to have passed the onDragStart property by some parent component.

Breadcrumb notifies parent on drag start and end

7c37b06

oandregal force-pushed the update/dnd-handle branch from 157cb2c to 7c37b06 Compare August 20, 2018 12:16

Move deprecations to 3.7 version

9d4793a

oandregal commented Aug 20, 2018

View reviewed changes

The breadcrumb should not be shown above overlays

9999a4f

oandregal requested review from jasmussen, aduth and youknowriad August 21, 2018 12:19

oandregal added the [Feature] Drag and Drop Drag and drop functionality when working with blocks label Aug 21, 2018

oandregal commented Aug 21, 2018

View reviewed changes

oandregal mentioned this pull request Aug 24, 2018

Refactor Draggable to decouple drag handle from the DOM node being dragged #9311

Merged

oandregal closed this Aug 27, 2018

oandregal deleted the update/dnd-handle branch August 27, 2018 15:47

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use the breadcrumb as the draggable handle #8764

Use the breadcrumb as the draggable handle #8764

oandregal commented Aug 9, 2018 •

edited

Loading

oandregal commented Aug 9, 2018

oandregal commented Aug 9, 2018

ZebulanStanphill commented Aug 9, 2018

oandregal commented Aug 10, 2018 •

edited

Loading

oandregal commented Aug 13, 2018

oandregal Aug 17, 2018

oandregal Aug 17, 2018

oandregal Aug 17, 2018

oandregal Aug 20, 2018

oandregal Aug 20, 2018

oandregal Aug 21, 2018

oandregal Aug 20, 2018

ZebulanStanphill Aug 20, 2018 •

edited

Loading

oandregal Aug 21, 2018

chrisvanpatten Aug 21, 2018

oandregal commented Aug 21, 2018

oandregal Aug 21, 2018

ZebulanStanphill commented Aug 21, 2018

jasmussen commented Aug 22, 2018

oandregal commented Aug 22, 2018 •

edited

Loading

jasmussen commented Aug 22, 2018

ZebulanStanphill commented Aug 22, 2018

oandregal commented Aug 27, 2018

Use the breadcrumb as the draggable handle #8764

Use the breadcrumb as the draggable handle #8764

Conversation

oandregal commented Aug 9, 2018 • edited Loading

Current status / Open questions

TODO

Test

oandregal commented Aug 9, 2018

oandregal commented Aug 9, 2018

ZebulanStanphill commented Aug 9, 2018

oandregal commented Aug 10, 2018 • edited Loading

oandregal commented Aug 13, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ZebulanStanphill Aug 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oandregal commented Aug 21, 2018

Choose a reason for hiding this comment

ZebulanStanphill commented Aug 21, 2018

jasmussen commented Aug 22, 2018

oandregal commented Aug 22, 2018 • edited Loading

jasmussen commented Aug 22, 2018

ZebulanStanphill commented Aug 22, 2018

oandregal commented Aug 27, 2018

oandregal commented Aug 9, 2018 •

edited

Loading

oandregal commented Aug 10, 2018 •

edited

Loading

ZebulanStanphill Aug 20, 2018 •

edited

Loading

oandregal commented Aug 22, 2018 •

edited

Loading