Render UI with both front and admin theme

So, the idea is to load preview and builder in web components with custom element & shadow dom.

I will have a little look. It may be related to #3542003: Responsive viewports with iframes

I move to beta2 to explore the declarative shadow dom idea following JohnAlbin talk :https://www.youtube.com/watch?v=04YKlSNf89o

Let's be careful about JS events in and out the sandbox.

If it works, we will have 2 proposals:

• we keep display builder in front theme and we display contextual panels with admin theme
• we move display builder to admin theme and we display builder abd preview panel with front theme

We can do both, it will allow us:

• to edit pattern preset for admin UI
• to propose a field widget forUIP2 sources field working in both front and admin themes

Very exciting but too ambitious for beta2.

Ongoing investigations.

We can't easily wrap a single island in db-isolate, maybe because of AJAX / Behaviours / HTMX swapping.

But we can wrap full regions, and we have 2 ways of doing that:

• Display Builder with admin theme & View panels (both sidebar & main regions) with front theme
• Dispaly Builder within front theme and contextual region with admin theme

The current proposal in the MR is doing the second with the addition of a DeclarativeShadowDomRenderer service wrapping in a db-isolate Web component:

• Create the declarative shadow dom ✅
• Load the admin theme assets libraries and keep them isolated ⚠️ ok but we don't render script_bottom asset libraries
• Run the renderer with the admin theme templates ❌ (must not be done in DeclarativeShadowDomRenderer but in the islands' HTMX swap response)

Proposal nearly finished:

• Load the admin theme assets libraries and keep them isolated with a declarative shadow dom >> ✅ DONE in DeclarativeShadowDomRenderer ⚠️ but we don't render script_bottom asset libraries
• Wrap contextual panels in this declarative shadow dom (used in db-isolate web component) >> ✅ DRAFTED in ProfileViewbuilder
• Render conetxtual panels with the admin theme (to load the expected templates and execute the expected hooks) >> ✅ DONE in DisplayBuilderEventsSubscriber ⚠️ but we miss the asset library specific to the islands (example: UI Styles widgets)

There may be a cleaner and more generic way of doing that, but it works already well.

We can't easily wrap a single island in db-isolate, maybe because of AJAX / Behaviours / HTMX swapping.
But we can wrap full regions, and we have 2 ways of doing that...

It works now: we can apply declarative shadow dom island by island!

Thanks to this, we have a simpler logic fixing the previous issues:

• Load the admin theme assets libraries and keep them isolated with a declarative shadow dom >> ✅ DONE in DeclarativeShadowDomRenderer ⚠️ but we don't render script_bottom asset libraries
• Wrap contextual panels in this declarative shadow dom (used in db-isolate web component) >> ✅ DONE in DisplayBuilderEventsSubscriber

Remaining work

not much...

Playwright tests:

waiting for locator('.db-island-builder > slot.db-dropzone')
       at objects/DisplayBuilder.ts:111
      109 |     await this.htmxReady()
      110 |
    > 111 |     await expect(target).toBeVisible()

Add a specific theme: admin attribute in Drupal\display_builder\Attribute\Instance ?

It doesn't work anymore since we merged #3529064: Follow Core 11.3's HTMX integration

Works again after new rebase from 1.0.x.

Tested with Gin & Claro.

Jean, do you want to have a look? It is not a proper review because the pipeline is not green yet and because there is some subjects to discuss before, but it would be great to have your opinion.

I have added a CSS zoom property to address the issue of admin theme spacing VS available space in drawer.

Let's compare https://caniuse.com/declarative-shadow-dom with https://www.drupal.org/docs/getting-started/system-requirements/browser-...

1. The latest release of each of the latest two supported major versions of:
   1. Desktop browsers
      • Google Chrome ✅
      • Firefox ✅
      • Safari ✅
      • Microsoft Edge ✅
      • Opera ✅
   2. Mobile browsers
      • Safari for iOS ✅
2. The latest supported release of the latest major version of:
   1. Desktop browsers
      • Firefox ESR ✅ (current version: 140)
   2. Mobile browsers
      • Chrome for Android ✅
      • Chrome for iOS ✅
      • Opera Mini (except for 'extreme data savings' mode) ❌ (0,03% of market share)
      • Samsung Internet ✅

Pipeline is green :)

2 thoughts:

• It may also be the opportunity to drop wysiwyg_fixes.js 😉
• If a JS is not working as expected, it may be because we are not loading it in DeclarativeShadowDomRenderer. See snippet.

  public function render(array $content, bool $admin = FALSE): array {
    ...
          <js-placeholder token="{{ placeholder_token }}">
          <!--js-bottom-placeholder token="{{ placeholder_token }}"-->
   ...
    // Create placeholder strings for these keys.
    $types = [
      'styles' => 'css',
      'scripts' => 'js',
      // We are not rendering script_bottom placeholder, in order to not
      // trigger BigPipe. Is it a mistake?
    ];

Wysiwig problems and part of wysiwyg_fixes seems related to ajax as there is more problems now it can not fix #3561474: WYSIWYG block behavior problems with ajax.

Will review today to see if it help.