Changes to overrides are not loaded unless published

I started seeing this problem with regular code components as well. Before updating the issue title and summary, can you please confirm, @lauriii? This seems like a regression after 0.2.0-alpha1.

Actually, the issue summary is way too ambiguous:

the updates do not take effect in preview

Which preview?

1. The one in the code component editor?
2. The one when hovering the component list?
3. The XB canvas' preview of a content entity's component tree?

It kinda sounds like it's #1, but then the STR make it sound like it's #3.

If it's #3: does that "block override code component" (which is highly experimental!) happen to be placed in a page region, or in the content entity's XB field? If it's in a page region, this is a duplicate of 🐛 Changes to code components in global regions is not loaded until published Active .

It is number 3, the XB canvas' preview. This is different from 🐛 Changes to code components in global regions is not loaded until published Active because with overrides, the block doesn't have to be placed in a page region for this bug to occur.

Thanks for confirming/clarifying.

The culprit is \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::renderComponent()'s:

    // ⚠️ Highly experimental: allow a Block plugin's Twig template to be
    // overridden and rendered using an XB JavaScriptComponent instead.
    $js_overrides = $this->entityTypeManager
      ->getStorage(JavaScriptComponent::ENTITY_TYPE_ID)
      ->loadByProperties([
        'block_override' => $block->getBaseId(),
        'status' => TRUE,
      ]);
    // ⚠️ This assumes that all such overrides are accessible to all users! If
    // that were not the case, presentation of the same block would vary between
    // users, which is unacceptable.
    // Therefore, this assumes that every user, even anonymous users, can access
    // the rendered result of the found JavaScriptComponent.
    // @see \Drupal\experience_builder\Element\AstroIsland::preRenderIsland()
    // @see https://www.drupal.org/project/experience_builder/issues/3508694
    if (count($js_overrides) == 1) {
      $js_component_for_block_base_plugin = reset($js_overrides);
      assert($js_component_for_block_base_plugin instanceof JavaScriptComponent);
      $build['#theme'] = 'block__' . strtr($build['#base_plugin_id'], '-', '_') . '__as_js_component';
      $build['#js_component'] = $js_component_for_block_base_plugin;
      // Update cacheability.
      $build['#cache']['tags'] = $js_component_for_block_base_plugin->getCacheTags();
      $build['#cache']['contexts'] = $js_component_for_block_base_plugin->getCacheContexts();
      $build['#cache']['max-age'] = $js_component_for_block_base_plugin->getCacheMaxAge();
    }

… because that doesn't perform auto-save checking, because everything that ✨ Code Components as Block Overrides, step 1 Active did was a highly experimental hack 😅

Which is why to make this code component auto-save load, we're now needing to modify the block ComponentSource! 🤪

We can hack this further for now, but we really need to work to refactor all the ⚠️ Highly experimental comments away: they're there for a reason!

Demoting priority, because such experimental features cannot be critical.

The fix is:

diff --git a/experience_builder.block_overrides.inc b/experience_builder.block_overrides.inc
index 1b396acf4..f41b45c38 100644
--- a/experience_builder.block_overrides.inc
+++ b/experience_builder.block_overrides.inc
@@ -172,7 +172,7 @@ function _experience_builder_render_js_component_from_block_element(array $block
   //   through an intermediary ephemeral Component entity?
   $source = JsComponent::createConfigEntity($js_component)->getComponentSource();
 
-  $build = $source->renderComponent(['props' => $props], $instance_uuid);
+  $build = $source->renderComponent(['props' => $props], $instance_uuid, TRUE);
   assert($source instanceof JsComponent);
   $source->setSlots($build, $slots);
   return $build;

… except that the TRUE cannot be hardcoded, but should happen only when appropriate, as described over at #3512385-4: Changes to code components are not visible in A) preview-on-hover, B) global regions until published → .

IMHO it's fine to hard-code this as-is, which would result in the auto-saved "block override" code component to be visible even OUTSIDE XB's UI. IMHO that's fine because this is a highly experimental feature that needs to be rewritten anyway into its own component source plugin, which means it's a waste of time to work on passing "XB preview or not" context into this. If we can figure it out in <30 mins, we can do that, otherwise should just commit that one-liner IMHO.