Overview

Extracted from #3512385-5: Changes to code components are not visible in global regions until published:

⚠️ AFAICT this also affects the component preview upon hovering the list of available components:

Proposed resolution

  1. Always call ComponentSourceInterface::renderComponent() with isPreview: TRUE in ComponentSourceInterface::getClientSideInfo()
    diff --git a/src/Plugin/ExperienceBuilder/ComponentSource/BlockComponent.php b/src/Plugin/ExperienceBuilder/ComponentSource/BlockComponent.php
    index 4fbac989c..adb573f8d 100644
    --- a/src/Plugin/ExperienceBuilder/ComponentSource/BlockComponent.php
    +++ b/src/Plugin/ExperienceBuilder/ComponentSource/BlockComponent.php
    @@ -302,7 +302,7 @@ final class BlockComponent extends ComponentSourceBase implements ContainerFacto
           return ['build' => []];
         }
     
    -    return ['build' => $this->renderComponent([], $component->uuid())];
    +    return ['build' => $this->renderComponent([], $component->uuid(), TRUE)];
       }
     
       /**
    diff --git a/src/Plugin/ExperienceBuilder/ComponentSource/GeneratedFieldExplicitInputUxComponentSourceBase.php b/src/Plugin/ExperienceBuilder/ComponentSource/GeneratedFieldExplicitInputUxComponentSourceBase.php
    index c55528b5b..39653166a 100644
    --- a/src/Plugin/ExperienceBuilder/ComponentSource/GeneratedFieldExplicitInputUxComponentSourceBase.php
    +++ b/src/Plugin/ExperienceBuilder/ComponentSource/GeneratedFieldExplicitInputUxComponentSourceBase.php
    @@ -603,7 +603,7 @@ abstract class GeneratedFieldExplicitInputUxComponentSourceBase extends Componen
     
         return [
           'source' => (string) $this->getSourceLabel(),
    -      'build' => $this->renderComponent([self::EXPLICIT_INPUT_NAME => $default_props_for_default_markup], $component->uuid()),
    +      'build' => $this->renderComponent([self::EXPLICIT_INPUT_NAME => $default_props_for_default_markup], $component->uuid(), TRUE),
           // Additional data only needed for SDCs.
           // @todo UI does not use any other metadata - should `slots` move to top level?
           'metadata' => ['slots' => $this->getSlotDefinitions()],
    
  2. Ensure that any auto-save change is immediately reflected in the hovering, i.e. ensure the necessary client-side (and server-side) cache invalidation happens. The test coverage being added in #3518832: ComponentSource robustness: add `ComponentSourceTestBase::testGetClientSideInfo()` should make it relatively straightforward to test this in JsComponentTest.

User interface changes

Component hover (instantaneously, aka without refreshing) shows the auto-saved (draft) version of a code component.Changes to code components are not visible in global regions until published

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

wim leers created an issue. See original summary.

wim leers’s picture

Component: Component sources » Internal HTTP API
wim leers’s picture

Issue tags: +stable blocker
wim leers’s picture

Title: Changes to code components are not visible in preview-on-hover-component-list until published » [PP-1] Auto-saved changes to code components are not visible in preview-on-hover-component-list until published
Issue summary: View changes
Status: Active » Postponed
Issue tags: +Needs tests
Parent issue: » #3521002: [META] Maintainable client-side data model + internal HTTP API
Related issues: +#3518832: ComponentSource robustness: add `ComponentSourceTestBase::testGetClientSideInfo()`
wim leers’s picture

Title: [PP-1] Auto-saved changes to code components are not visible in preview-on-hover-component-list until published » Auto-saved changes to code components are not visible in preview-on-hover-component-list until published
Assigned: Unassigned » isholgueras
Status: Postponed » Active

This is now trivial to add test coverage for thanks to #3518832: ComponentSource robustness: add `ComponentSourceTestBase::testGetClientSideInfo()`. All we'd need to do is:

  1. override ComponentSourceTestBase::testGetClientSideInfo() in JsComponentTest to create a draft component for one of the tested code components
  2. update expectations.
wim leers’s picture

#5.1 is conceptually super similar to #3520052: Auto-saved changes to component are not loaded in preview canvas when component is inside a slot — chances are you can copy/paste some code, or, better yet, extract it into a trait for testing purposes! 😄

wim leers’s picture

Assigned: isholgueras » thoward216
hooroomoo’s picture

Just an FYI, if you see that the hovered preview doesn't render anything when you FIRST add a JS component to your library, it's because a regression was introduced yesterday #3521819: Hovered preview for JS components in library not working anymore.

thoward216 made their first commit to this issue’s fork.

thoward216’s picture

Status: Active » Needs review
sanket.tale’s picture

I reviewed the proposed solution and merge request, and it looks good overall. However, the pipeline is still failing. I tried to solve it, but couldn't resolve the issue. I believe the failure is due to the image (600x400.png) unexpectedly being found in the iframe and the client.js script not loading correctly. Please check the image logic and ensure the script loads properly during testing.

wim leers’s picture

Status: Needs review » Needs work
Issue tags: -Needs tests

Yep, genuine test failure:

     ✘ Get client side info
       ┐
       ├ Failed finding selector 'script[blocking="render"][src*="experience_builder/ui/lib/astro-hydration/dist/client.js"]'
       ├ Failed asserting that 0 is equal to 1 or is greater than 1.                                                         
       │
       │ /builds/issue/experience_builder-3516705/tests/src/Kernel/Plugin/ExperienceBuilder/ComponentSource/ComponentSourceTestBase.php:336
       │ /builds/issue/experience_builder-3516705/tests/src/Kernel/Plugin/ExperienceBuilder/ComponentSource/ComponentSourceTestBase.php:363
       │ /builds/issue/experience_builder-3516705/tests/src/Kernel/Plugin/ExperienceBuilder/ComponentSource/JsComponentTest.php:756
       ┴

So I'm confused about why this was marked Needs review? 🤔

tedbow’s picture

This makes the problem in #3521843: JS component slots and props don't appear in the preview canvas until published worse because since it no longer showed the saved config compiled js for hovering and since auto-save doesn't work either there is no preview on hover

thoward216’s picture

@tedbow re #14 - are you saying that #3521843: JS component slots and props don't appear in the preview canvas until published is the root cause of the failing test here? And that issue should be resolved first?

tedbow’s picture

@thoward216 nope I assume this should be able to be fixed here. Just related to the other problem. in manual testing of this MR I do see it fixing the problem of hover preview not being updated

thoward216’s picture

Status: Needs work » Needs review

Tests are now passing.

wim leers’s picture

Assigned: thoward216 » Unassigned
Status: Needs review » Reviewed & tested by the community

wim leers’s picture

Status: Reviewed & tested by the community » Fixed
mayur-sose’s picture

Issue 1: Preview not updating after modifying component properties

  • Steps to Reproduce:
    1. Click on the + Add New button.
    2. Keep the default JS code as it is and click on Add to components from the side panel.
    3. Edit component by changing its background color to bg-blue-200.
    4. The right-hand preview section displays the correct color change.
    5. Navigate back to the Canvas page from the navigator.
    6. Hover over the card component.
  • Observation: It seems that navigating back to the canvas is not triggering an update or cache refresh for the hover preview. The component is still stuck with the initial preview state.

Issue 2: Inconsistent updates after drag-drop and publish

  • Steps to Reproduce:
    1. Drag and drop the component onto the page.
    2. Publish the changes and reload the page.
    3. The changes are correctly reflected.
    4. Edit the card again and change the background color to bg-blue-500.
    5. Navigate back to the Canvas page.
    6. Hover over the card component.
  • Expected: The new background color should be visible both in the canvas and on hover.
  • Actual: The hover preview and canvas still display the previous state (bg-blue-200).

lauriii’s picture

@mayur-sose I can reproduce both issues. Could you file new issues for these? 🙏

mayur-sose’s picture

sure @lauriii

wim leers’s picture

@mayur-sose and please leave a comment here linking to those 🙏

Status: Fixed » Closed (fixed)

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