Auto-saved code component changes are not reflected in content preview and component library preview thumbnail

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

How could this be a duplicate of #3516705: Auto-saved changes to code components are not visible in preview-on-hover-component-list until published 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 #3516705: Auto-saved changes to code components are not visible in preview-on-hover-component-list until published 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 #3520052: Auto-saved changes to component are not loaded in preview canvas when component is inside a slot'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 #3522217: JsComponent-sourced rendered component instances lack cacheability of underlying config entities (+ first-party imports + auto-save tag when previewing) 😬 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? 🙏

#9 shows #3508937: Global AssetLibrary should render with its auto-saved state (if any) when rendered in the XB UI — now that we landed #3516390: Compile Tailwind CSS globally for code components. 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 #3508937: Global AssetLibrary should render with its auto-saved state (if any) when rendered in the XB UI.

→ 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 #3522217: JsComponent-sourced rendered component instances lack cacheability of underlying config entities (+ first-party imports + auto-save tag when previewing), and that didn't help. I recorded a video, I'll post it shortly.

Even if #13 says #3522217: JsComponent-sourced rendered component instances lack cacheability of underlying config entities (+ first-party imports + auto-save tag when previewing) 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.

#3522217: JsComponent-sourced rendered component instances lack cacheability of underlying config entities (+ first-party imports + auto-save tag when previewing) is in!

#3522217: JsComponent-sourced rendered component instances lack cacheability of underlying config entities (+ first-party imports + auto-save tag when previewing) did fix the backend problem! 🎉

Two tiny bits need to go in on the frontend, and we should be good!

I marked #3525374: Include compiled CSS from global asset library when displaying component library preview thumbnails postponed on this issue, so it's cleaner to tackle.

#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.

#3525374: Include compiled CSS from global asset library when displaying component library preview thumbnails 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 Needs tests, 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 Needs review.

🎉