Improve the way to detect if the code component has drupalSettings

I think what we'll want to do here is something similar to how we do first-party imports, where the XB front-end parses the JS to determine the dependencies and includes that information in the request payload when saving the component. We might need to add a new key to the js_component config schema to store the info if dependencies doesn't work for depending on Drupal libraries.

#2++

That's literally what I wrote at https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...

We'll need something similar for code components fetching data via HTTP (either local aka Drupal-served URLs or remote URLs), because that is what needed to in the future add server-side prefetching of data without breaking existing code components or leaving them behind.

All of this is basically to say: dependency information is crucial! Without dependency information, the backwards compatibility break risk assessment is "unavoidable, will be painful and require manual intervention", whereas otherwise it can be "avoidable, will either be transparent or precise instructions can be provided".

IOW: it's a matter of future DX for code component creators and update path feasibility for XB maintainers. See point 3 of my comment #12 in the issue that landed this → .

Step 1 here is the front end providing that dependency information, because what 📌 Populate data to drupalSettings to enable Dynamic Code Components Active introduced (and what's quoted in the issue summary) is the best the back end can do, since it cannot parse JS.

So, my concern in one sentence: we must be able to provide a long-term update path for code components, which includes not breaking any code components created on beta1.

Implementation outline

My interpretation of what @effulgentsia and I are saying:

1. client-side to pass drupalSettings.xbData.v0 dependency information however it sees fit — note this COULD be all of the data initially, and just more granularity later! What matters is that we know which code components use this at all, and which version they're on. Which is exactly what the pragmatic approach in #3531249 (i.e. in HEAD did)
2. update \Drupal\experience_builder\Entity\JavaScriptComponent::updateFromClientSide() to consume it
3. remove the parsing logic in ::getRequiredXbDataLibraries() and it with a new config entity property on the JavaScriptComponent config entity type to store it instead
4. update the logic in ::getAssetLibraryDependencies() to use that new config entity property

IOW: the exact same pattern that 🐛 Components sourced from JsComponent are missing source component cacheable metadata Active did, just not stored as an enforced config entity dependency.

Choice: beta blocker 🆚 stable blocker + update path by relying on heuristics

This means that this can indeed be a , not a , but only if the logic in getRequiredXbDataLibraries() can be updated to work with reasonable reliability, because then we can transform whatever that logic computes to explicit dependency information in an update path.

Per #3531249-18: Populate data in `drupalSettings` to enable simple use cases in dynamic code components → :

The front-end API will consume this settings with methods (not decided yet) like getPageData() (for title and breadcrumb) and getSiteData() (for base URL and branding).

That's why I think detecting the presence of such calls in the JS is doable in a saved config entity, which means that an update path after beta1 would be feasible.

So: I propose to indeed keep this as a , but I might have missed something 😇

wim leers → credited balintbrews → .

Discussed with @balintbrews, he's on board 👍

+1 to this plan