- Issue created by @longwave
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
When we are previewing a component that does not contain any HTML tags, detect this special situation and wrap them in a container, so they can still be previewed and manipulated correctly by the UI.
How do you propose doing that for code components?
Wouldn't be more accurate?
- 🇬🇧United Kingdom longwave UK
There is nothing stopping an SDC or a block outputting a text string only, with no surrounding tags? I haven't tested but I think this would render as text in the preview but would not be draggable as there is no element to receive the click.
Code components are more tricky and would require hooking into the Astro renderer I guess, I haven't thought about or looked into that yet. Perhaps that can wait for a separate issue.
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
I knew there were existing issues for this problem space already, but couldn't find them. Just stumbled upon one: 🐛 [Needs design] Previews of pages containing (dynamically) empty blocks are malformed Active .
That's basically the same problem:
- Depending on explicit input ("settings" for block plugins, "props" for SDCs), the block may result in an empty render array to render:
$content = $block->build(); if (Element::isEmpty($content)) { $content['#access'] = $access; return $content; }
—
\Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::renderComponent()
- Core has a solution for this:
PreviewAwarePluginInterface
, but nothing in core actually uses this to render an alternative representation; only Layout Builder does it in a heavy-handed way:
if ($event->inPreview()) { if ($block instanceof PreviewFallbackInterface) { $preview_fallback_string = $block->getPreviewFallbackString(); } else { $preview_fallback_string = $this->t('"@block" block', ['@block' => $block->label()]); } // @todo Use new label methods so // data-layout-content-preview-placeholder-label doesn't have to use // preview fallback in https://www.drupal.org/node/2025649. $build['#attributes']['data-layout-content-preview-placeholder-label'] = $preview_fallback_string; if ($is_content_empty && $is_placeholder_ready) { $build['content']['#markup'] = $this->t('Placeholder for the @preview_fallback', ['@preview_fallback' => $block->getPreviewFallbackString()]); } }
… we could use the same strategy, but wrap that string in a wrapper.
Thoughts? And … should we just merge this into 🐛 [Needs design] Previews of pages containing (dynamically) empty blocks are malformed Active ? 😅
- Depending on explicit input ("settings" for block plugins, "props" for SDCs), the block may result in an empty render array to render:
- 🇬🇧United Kingdom longwave UK
Yep let's handle this in 🐛 [Needs design] Previews of pages containing (dynamically) empty blocks are malformed Active
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
Reopening per @lauriii at #3497990-18: [later phase] Support Block's PreviewAwarePluginInterface (and similar for other component sources) → .
Thanks to 📌 Expand `::getClientSideInfo()` test to all ComponentSource plugins Active , the
sdc.xb_test_sdc.image-optional-without-example
test case (added by 📌 ComponentMetadataRequirementsChecker::check() should validate that the example(s) actually match the JSON schema Active ) for\Drupal\Tests\experience_builder\Kernel\Plugin\ExperienceBuilder\ComponentSource\ComponentSourceTestBase::testGetClientSideInfo()
already provides an empty string example.We of course only want to do this when rendering a component for XB previewing purposes (so:
ComponentSourceInterface::renderComponent(isPreview: TRUE)
). Which means the following are closely related — until they're both in, we'll need to be careful with the test coverage:- 🐛 Changes to code components are not visible in preview-on-hover-component-list until published Active
- 📌 Only run XbTwigExtension inside XBPreviewRenderer Active
(Because the test coverage that #3518832 added is still expecting the component previews to be rendered with
isPreview: FALSE
, which #3518832 is fixing/changing 👍) - 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
… thinking of this some more, should we use a similar strategy here as for 📌 Improve server-side error handling Active ? 😇
- 🇫🇮Finland lauriii Finland
Would there be a way for us to only add the wrapper if a component doesn't render anything or renders a text node?
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
If we go as far as 📌 Improve server-side error handling Active : possibly.
But my fear is that Block plugins' highly optimized rendering (which XB currently does not yet support — 🐛 Placeholders/#lazy_builder is not supported for block component rendering Active is fixing that) will prevent us from doing this.
In fact, I think 🐛 Placeholders/#lazy_builder is not supported for block component rendering Active should be a blocker to this; otherwise we can't guarantee that this is implemented correctly/completely the first time.