Retain the placement of components within the preview when inserting a component

The issue summary appears to state "there must be zero layout shifts".

But I don't see how that's possible?

It's not clear to me what you're proposing exactly. 😇 Are you asking to reserve dummy space at the start/end of each slot?

What I can imagine working: as soon as a component is being dragged from the left sidebar, animate in the "candidate drop target" styling for each empty slot + "candidate drop targets" at the start and end of each non-empty slot, so that while dragging the component over possible places, there's no more layout shift. 👈 That's my imagination, because I really can't infer it from the description or proposed solution in the issue summary 😅

I'm proposing that we display a blue line where the component would be placed. This would be absolutely positioned so that it doesn't cause layout shift. There's a screenshot in the proposed solution section of the issue summary for how this could look like.

I agree with Laurii, as this is a similar pattern that we see across other visual builders. Here's an example from our last design mock:

This needs more testing, but I think I managed to make it work. What I'm really excited about is that I also found a way to tweak the threshold we have on detecting drop targets. Still not perfect, but so much better!

With this change, hiding the example/default content in an empty slot didn't make sense anymore, so I removed that code. I had to make sure we're only able to insert components above the example content. One known issue is that this is not solved for components that are newly dropped from the component list. I'd like to create a follow-up issue for that.

#3: ahhhhhhhh! You stated "similar to this highlight", but I had no idea I had to look at that blue line 😅 That was the crucial missing info, thanks! 👍 (A GIF would've made this obvious, thanks, @bostonjillian!)

This is a really nice improvement for adding components. I noticed this re-introduces 🐛 Retain the space consumed by a component when it's being dragged Fixed when dragging components from section to another. I'm wondering if you had a specific reason for this?

I also noticed it's still challenging to drag components into some positions. Empty slots are pretty painful and it's hard to add components to the beginning / end of the canvas. We could move some of these issues to a separate issue.

NW for at least the first paragraph in #10.

FYI, we have two additional issues to improve drag and drop: 🐛 Adding a component with slots does not register the slots as children Fixed and 🐛 Make it easier to drag and drop content to the top or bottom of the page Active .

I noticed this re-introduces #3469895: Retain the space consumed by a component when it's being dragged when dragging components from section to another. I'm wondering if you had a specific reason for this?

@laurii, can you please elaborate on what you noticed? What is being reintroduced? The issue you referred to renders the ghost element — which shows you where you are about to drop something — as the same element as it was before you pick it up with a lower opacity.

I have a feeling that you might want the element that's being dragged to still also remain in place, maybe with a lower opacity, while it's being dragged? If so, we never had that implemented.

I also noticed it's still challenging to drag components into some positions. Empty slots are pretty painful and it's hard to add components to the beginning / end of the canvas. We could move some of these issues to a separate issue.

Yes, there are still plenty of improvements to be made! I still think this tweak I found here for detecting the threshold of different drop targets makes a big difference, and should land before we do more work on drag & drop.

I had a chance to do a quick call with @laurii to make sure we're on the same page. I now understand that in a way this is a step backwards, because when you move an existing component on the preview, things immediately rearrange. While we didn't do anything to prevent that previously, just by the nature of keeping the same height for the ghost element we prevented a lot of movement in scenarios where you're moving components inside a slot, or when you have a similar height e.g. in a two-column component.

So in other words, what I'll solve next is keeping the dimensions of the spot intact from where we pick something up.

This looks very nice 😍

Awesome work on this @balintbrews! 💯 👏 This feels really nice to use! 🤩 🚀 I believe this will pair nicely with 📌 Improve UX of adding new sections Needs review which will bring even more clarity on to which section the component is being dragged into.

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