Components sourced from JsComponent are missing source component cacheable metadata

Needs tests. Normally I write a kernel test which implements CacheTagsInvalidatorInterface to track invalidations, so we could have a Page using a JS component. Then re-save the JS component and validate the cache tag invalidated.

But I suppose we could just render a page and verify the JS component cache tags are present now.

Added a basic set of assertions to prove that the JS component's cache metadata is added to the render array, but I'm leaving the "needs tests" tag here because we should still have coverage to prove that a nested component's cache tags are added.

wim leers → credited larowlan → .

Great find, @mglaman! 🙏

Based on the issue summary, I expected our ComponentTreeHydratedTest to need updating. I'm pleased to see it does 👍

✨ Create a ComponentSource plugin for JS components Active is the issue that added the JsComponent source, and it did add the following expectation:

                                'tags' => ['config:experience_builder.component.js.my-cta'],

I just checked that issue + its MR for the substring "cach" and found no discussion about this. So we missed that in that >1000 net new LoC MR. 😞

Then, as @larowlan points out on the MR, 📌 Code Components should render with their auto-saved state(if any) when rendered in the XB UI Active subsequently forgot to add \Drupal\experience_builder\AutoSave\AutoSaveManager::CACHE_TAG when appropriate.

And finally:

we should still have coverage to prove that a nested component's cache tags are added

Indeed, this is necessary since a few weeks; it's something we missed in ✨ Store and calculate dependencies in `JavaScriptComponent` Active . It'd have been easier to spot if #3498889 didn't miss it originally.

Conclusion

We've been treating JS components ("code components") the same as other components sourced from simpler sources, but these are much more complex: they're assembled from 1 (now possibly multiple) config entities, and when rendered with isPreview: TRUE, they can be even be assembled from auto-save data (which could be changing any second)!

However, it was the reliance on separate CSS+JS URLs for auto-saved JS components that made this actually work fine : all CSS/JS changes would be reflected correctly (and yes, those use Cache-Control: private, no-store). 👈 This worked fine, and is what all of us were dead-focused on 😇

This issue is specifically reporting that the cacheability metadata being missing is a problem when using the live (non-auto-saved) versions of code components, i.e. when browsing as an end user a live site that is powered by (changed) JS components! That's a crucial thing we haven't been spending enough brain cycles on 😅🙈

Retitling for clarity.

FYI: 🌱 [META] Production-ready ComponentSource plugins Active 's lists → a whole sequence of kinda similar "now make it work correctly+well for live sites" remaining issues for the BlockComponent source!

This is well on its way — and a whole range of tests fail thanks to recent test infrastructure additions, which makes sense: \Drupal\Tests\experience_builder\Kernel\Plugin\ExperienceBuilder\ComponentSource\JsComponentTest::testRenderJsComponent()'s current expectations expect no cache tags; this changes that! 🥳