Refine dragging behavior and design in Layers menu

This seems related to 📌 Consider using SortableJS spill plugin when dragging sections into layout Active ?

📌 Improve the page hierarchy display Active is in!

hooroomoo → changed the visibility of the branch 3470594-layers to hidden.

The red color is kind of confusing. I'm not really sure what it's supposed to indicate. That you can't drag it into that location? I'm not sure if that's the best affordance. It might make sense to just show the closest place where it can be dragged to and avoid showing where it cannot be dragged. I think we should talk to Renee and Jillian from Acquia UX folks to find a solution to this 😇

@hooroomoo: deprioritizing per #3454094-77: Milestone 0.1.0: Experience Builder Demo → .

#13 The red/pink color to the clone for debugging purposes 😅

#15: 🤣 I was hoping you'd say that 😆

Jotting notes down here

1. The more deeply nested you get, the harder it is to place components correctly in the right slots.

   Still needs to be addressed

2. Several parts of a SortableContainer element with slots have the data-xb-uuid attribute since it is used when an element is being dropped into the slot target that has data-xb-uuid so the dragging knows where the destination is. And also when a component with slots is the one being dragged, the data-xb-uuid is needed to know the origin. I want to see if it is possible to reduce the data-xb-uuid usage.
3. Add a test that swaps a component with slots with another component with slots

In the last commit, i commented out the css workarounds within the SortableJS initialization and added the ghost class option so we can hopefully find the root cause since the very similar functionality of Sortablejs is working in the preview.

The problem is, when we use the ghostClass, our custom ghost element styling is not being applied when dragging within the same parent. I See chrome gif. But what is strange is it's working in Safari (see Safari gif, other than the weird short blue line that appears on start but thats a later issue).

Both gifs are on the same MR, and showing dragging within a slot, then within the root level.

CHROME GIF our custom ghost does NOT appear:

SAFARI GIF our custom ghost DOES appear:

I first thought maybe SortableJS is having an issue with the DOM structure of each item... but not sure about that anymore if it works in Safari...

Crediting @balintbrews for finding the cause of the bug

Follow-up idea to elevate the layers UX even more: use actual component previews instead of abstract ghosts when dragging — i.e. like the ones in #3469856-52: The component preview should have a background: include theme's global asset libraries for component preview → .

Initially I thought that I'm against the idea at #21. I was testing this today for the first time on my own, and I thought that the layer tab is a very good tool for power users and people who need accessible technologies - and this is especially because of being visually cleaner.

But if it would be a per user setting to show or hide previews then it would be an improvement. Another improvement IMO would be to allow navigating from layers to props and back using the keyboard.

Relevant innovations and lessons learned in dragging would be welcome at 📌 Research accessibility of drag-and-drop grid interfaces. Active

Tried out the interactions on with the current branch and found a few oddities/areas that could be improved. An overall issue I encountered is that it wasn't clear where things could be dropped because there's not a great indicator to tell where valid drop zones are for slots vs a component vs two components next to each other

• It's confusing that reordering and dropping into a slot have the same styles. I would expect the slot to highlight in someway if a component is going to be placed in it
• When dropping a component into a closed slot it'd probably be better if that slot opened when a component is placed in it
• Hovering over a closed slot should open it so I can drop a component deeper into the tree without having to open it first
• ( end-with-slot.mp4 → )Things get twitchy when trying to drag a component into a slot or to the end of a list when there is an expanded component containing a slot at the end of the list
• ( expanded-no-move.mp4 → )It's hard to tell if an expanded component will be placed in the same spot because the indicator appears at the bottom of the expanded tree for the component
• ( move-far.mp4 → )With an expanded tree the indicator can unexpectedly jump quite far down because it's the closest drop target
• ( general-weirdness.mp4 → )There's some general weirdness with the indicator jumping around
• The placement indicator isn't visible when it is before/after a selected component

It would be interesting to know if you can set the e.dataTransfer.setDragImage to point to an iFrame (one that has been scaled too) to achieve the functionality described in #21.

I would be concerned though what we be able to show when dragging empty elements etc once we have the ability to build components. We would still need to be able to fall back to something more abstract like we have now.

Btw the white box with plain text in it that we have now could certainly be styled to look nicer (unless that already happened in the last few days, I've not actually checked!)

#23 Thank you for the thorough testing @ctrladel!

This issue addresses noticeable buggy behavior that's currently in head and further improvements to the dragging behavior will be done in a follow-up to get this in sooner since there's always something to tackle with drag and drop functionality.

Automatically closed - issue fixed for 2 weeks with no activity.