- Issue created by @mayur-sose
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
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?
- ๐ซ๐ฎFinland lauriii Finland
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.
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
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? ๐
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
#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:
- 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 - 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. - no auto-save โ auto-save:
- ๐บ๐ธUnited States bnjmnm Ann Arbor, MI
If I add cache busting strings to the
getCodeComponents
andgetComponents
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. - ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
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? ๐
- ๐ณ๐ฑNetherlands balintbrews Amsterdam, NL
#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; }
- Merge request !1004#3523130: Auto-saved code component changes are not reflected in content preview and component library preview thumbnail โ (Merged) created by Unnamed author
- ๐ณ๐ฑNetherlands balintbrews Amsterdam, NL
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.
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
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.
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
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.
- ๐ณ๐ฑNetherlands balintbrews Amsterdam, NL
#16: The global asset library is not in play here if we follow what I suggested in #11.
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
- ๐ณ๐ฑNetherlands balintbrews Amsterdam, NL
๐ 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 ๐).
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
#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 . - First commit to issue fork.
-
hooroomoo โ
committed 994a5d4f on 0.x authored by
balintbrews โ
Issue #3523130 by balintbrews, bnjmnm, wim leers, mayur-sose: Auto-saved...
-
hooroomoo โ
committed 994a5d4f on 0.x authored by
balintbrews โ