Canvas and hover preview out of sync after drag-drop and publish

I'm 95% confident this is a duplicate of 🐛 Changes to code components are not visible in preview-on-hover-component-list until published Active . Can you please check if you can still reproduce this?

How could this be a duplicate of 🐛 Changes to code components are not visible in preview-on-hover-component-list until published Active if it was discovered as part of QA'ing that issue? I tested it as well on latest HEAD and confirmed that what was loaded wasn't the autosaved version but what exists in the config entity.

How could anybody have known this was found by QA'ing 🐛 Changes to code components are not visible in preview-on-hover-component-list until published Active if it's neither mentioned in the issue summary nor linked as a related issue? 😅

#2 is still true — see \Drupal\Tests\experience_builder\Kernel\Plugin\ExperienceBuilder\ComponentSource\JsComponentTest::testGetClientSideInfo(). Doubly so because 🐛 Auto-saved changes to component are not loaded in preview canvas when component is inside a slot Active 's test coverage is also in as of today (2814d46f805f3a0a079af0b4fe96654628eae592).

That's why this is most likely a client-side invalidation bug. Either or both of:

1. no auto-save → auto-save: /xb/api/v0/config/component not getting refetched after it changes from having no auto-save to getting an auto-save, which causes the referenced JS + CSS URLs for code components to change
2. auto-save changing: the "preview-on-hover" iframe still being around and not re-fetching /xb/api/v0/auto-saves/js/… and/or /xb/api/v0/auto-saves/css/…

Tested on 2814d46f805f3a0a079af0b4fe96654628eae592. That seems to confirm it's only the first. See attached screencast.

If I add cache busting strings to the getCodeComponents and getComponents endpoint requests, the problem goes away. The underlying problem might only be with one of the two, but that narrowed things down pretty darn quick. It looks like the BE is equipped to provide us what we need, and the FE needs to change how it asks for it.

add cache busting strings

Do you mean: a query string that includes the current time? Does that mean you're saying you're getting a cached response from the server side? If so: then this would actually be a server-side bug (cache tags, baby!).

Which … makes me actually jump to thinking this is just a duplicate of 🐛 Components sourced from JsComponent are missing source component cacheable metadata Active 😬 And I wouldn't have spotted that because I'm testing with settings.local.php containing

$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';
$settings['cache']['bins']['page_cache'] = 'cache.backend.null';

🙈

@mayur-sose Can you test this again with #3522217 applied? 🙏

@wim-leers, I am still able to reproduce both the issues.

#9 shows 🐛 Global AssetLibrary should render with its auto-saved state (if any) when rendered in the XB UI Active — now that we landed 📌 Compile Tailwind CSS globally for code components Active . More context: We switched from saving the compiled Tailwind CSS in individual code components to saving it in the global asset library. This is the first time we're actually using the global asset library for assets that are needed for rendering, so it surfaced the need for 🐛 Global AssetLibrary should render with its auto-saved state (if any) when rendered in the XB UI Active .

→ Let's not use Tailwind CSS for testing this issue to identify clear boundaries of what we're trying to fix.

Here is an example code component for testing:

JavaScript:

export default function Card() {
  return <div className="card">Am I updating? 🕵️</div>;
}

CSS — NOT global CSS:

.card {
  padding: 2rem;
  font-size: 1.5rem;
  font-weight: 500;
  background-color: teal;
  color: white;
}

I did some investigation, turns out we were missing some needed client-side invalidation — see MR —, but that is not fixing all the issues. The preview thumbnail can still show stale data. I tried it on top of 🐛 Components sourced from JsComponent are missing source component cacheable metadata Active , and that didn't help. I recorded a video, I'll post it shortly.

Even if #13 says 🐛 Components sourced from JsComponent are missing source component cacheable metadata Active didn't fix it (and perhaps that's due to a bug I spotted in the current MR, perhaps not), #3522217 should land first because otherwise it wouldn't be clear how to debug/reason about this issue.

Realization while running, will verify in code tomorrow: this might be caused by the global asset library (auto-saved or not) not being an asset library dependency _yet_ of every code component’s asset library.

#16: The global asset library is not in play here if we follow what I suggested in #11.

🐛 Components sourced from JsComponent are missing source component cacheable metadata Active is in!

🐛 Components sourced from JsComponent are missing source component cacheable metadata Active did fix the backend problem! 🎉

Two tiny bits need to go in on the frontend, and we should be good! (Besides 📌 Include compiled CSS from global asset library when displaying component library preview thumbnails Active 😛).

#19: glad to hear #3522217 did fix it after all :) I was kinda losing my sanity with your prior observations that it wasn't 😄 But that's because there were still some bugs in there that I fortunately caught prior to merging.

📌 Include compiled CSS from global asset library when displaying component library preview thumbnails Active was 2 LoC that you confirmed to be working yesterday, most of the work was expanding test coverage 🤓 That's already in now 👍

This is tagged , but I don't see any, and it does seem disproportionate to the JS changes. 👍 Removing.

I'd be confident merging this based on the tag invalidation alone, but I do not know enough about the refetchOnMountOrArgChange bit, so leaving in .

🎉

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