Investigate drag-and-drop solution that removes the need to drop items into the preview iFrame

Dropping this in from slack to hopefully get a follow-up at some point (in the project management court now):

With ~100ish components on a page, here are some browser performance metrics from a high end laptop:

~45 second time from page load to rendering the XB UI with dev tooling enabled; ~20 seconds w/o.

INP with dev tools ~3-4 seconds. 1.2 seconds w/o

--

I know that XB is still very early in development, but wanted to raise some awareness about potential scalability problems that will naturally be MUCH harder to tackle later as an after-thought -- even moreso once disruptive changes are harder to justify!

Ugh related issue != Child issue

f.mazeikis → made their first commit to this issue’s fork.

I think this does a lot more than prove the concept now! For full details of what this MR does and doesn't do, see the nicely formatted description on the MR itself!

I enabled all the Olivero regions and the drop zone sizes got kinda weird. This isn't a fresh install so it's possible this is a hiccup that might not be reproducible but I wanted to capture it now just in case. It's a "cutting off" of sorts but different from 🐛 Preview gets cut off sometimes on a layout change Active

The content drop region got narrow after enabling the regions

I added outlines to each region to see how they are laid out, too.

RE #8 - I don't think this is to do with the overlay (in fact the overlay is correctly drawing on the regions as they are displayed. This seems to be an issue with Olivero - when you enable XB for the sidebar region but don't yet have any component in that region, the CSS grid layout gets confused.

I ran the following image past @wim leers recently after observing the same thing.

His response was that because of

{% if page.sidebar %}
  <div class="sidebar-grid grid-full">

in core/themes/olivero/templates/layout/page.html.twig simply exposing the sidebar is causing the page to render differently and it seems that Olivero was not built to render correctly if the sidebar is enabled but also empty.

enabled but also empty

I think this might be hitting on a general problem we need to figure out what to do about. It's common for Drupal themes to conditionally render wrapper elements (like the <div class="sidebar-grid grid-full"> example above) only if there's content to put into them, and to omit them if the content is empty, and the theme's CSS then is based on that assumption and might not handle the case of the wrapper elements existing with empty content because the HTML "never" exists in that state.

Never, that is, until XB puts an HTML comment there, making it no longer empty as far as Twig is concerned, but making it empty as far as the DOM is concerned.

We can make XB omit the HTML comment identifying the slot in the case where the content is empty, which would then let the Twig conditionals work and the wrapper element not be added, but if we did that, then how would you drag something into that slot?

So there's a conflict here between wanting the preview to be accurate, but also wanting the ability to drag content into an empty slot. I don't have any ideas at the moment for how to solve for both.

Just so it's official, based on the discussion I feel that my findings in #8 are very much out of scope and just something I happened to discover while reviewing this.

@hooroomoo has already codeowner-approved in the domains I would be able to approve.
tbh it's too darn huge to be able to give it a truly in depth review, but I'm not seeing any red flags and it's really nice overall. I think the best improvements will occur to us once it's actually in the codebase. We still need src and Kernel test signoff, though.

Re #11 - I think omitting the html comments for empty regions is ok! Our UX does not show/make available empty regions. The only way to add the first component to an empty region is to right click it and choose 'send to global region'.

So I think not rendering the comments in empty regions is fine. (But does lock us into that UX)

#14: That seems fine for now. At worst case, I could see us wanting to show the empty regions somehow in the layers panel. I don't think we have to think about this too much now but it doesn't seem to be fundamentally limited by the HTML comments, even if they may be connected today.

Marking as fixed since there's a commit 🎉 Great work @jessebaker and everyone!

🤩

I want to make sure we don't forget about #11/#14. Did that make it already into what was merged? If not, is there a follow-up for it?

RE #11 Oh good catch! ✨ When a global region is empty, don't render HTML comment annotations into it Active raised as a follow up!

This landed in the prior sprint, so untagging.

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