Populate data to drupalSettings to enable Dynamic Code Components

I added more details and what I propose as the data shape.

Note: spend zero seconds on making pageTitle work, until 🐛 Handle adding page title to content Active is in. Hardcode some string for now.

Added some implementation guidance.

#3: We need the page title in drupalSettings.xbData regardless of that. 🐛 Handle adding page title to content Active will enable the page title block to work, but we would like to support building a dynamic code component where users can access the raw page title and add custom markup around it. It was amongst our original goals for ✨ Code Components as Block Overrides, step 1 Active , but we dropped that due to the challenges with page title block. Or maybe what you're saying is that we need 🐛 Handle adding page title to content Active even to be able to populate it in drupalSettings.xbData? 🙂

I think it's ready for the first review round

Nice work here!

I'm missing three key things:

1. JavaScriptComponent config entities should at minimum declare that they depend on drupalSettings
2. JavaScriptComponent config entities should ideally declare that they depend on in drupalSettings — especially breadcrumbs data, because it massively worsens cacheability
3. a strategy for avoiding worsened cacheability and scalability (see MR comments for details)

I'm fine with a @todo + stable-blocking follow-up issue to address the dependency information, but shipping a 1.0 like this is a no-go.

There is only one thing left to do. How are the code component going to require that it depends on... breadcrumbs for example?

I still missing how, if I'm creating a code component, I'm going to depend on breadcrumb or pageTitle.

I mean, in the whole process as a user or XB user, I click in Add new, I get the editor and... where I define what features I will require?

I was playing around with a new schema Choice property, drupalSettings, similar to a blockOverride and list there all the options allowing developers to add it to the yaml files, maybe in the future adding them to the UI, but that's very much out of scope here.

Any thoughts here?

1. 👍 The current MR is based on the simple on/off presence of preg_match('/drupalSettings\.xbData/', $component->getJs(). I agree with the pragmatism until such a time we can use explicit import statements.
2. 👎 While better than when I reviewed it in #8 late last week, it still has too much of a negative impact on cacheability and hence scalability. See my analysis and rough proposal, and my implementation outline. That outline partially works. Next step: debug why \Drupal\experience_builder\Hook\ComponentSourceHooks::jsSettingsAlter() is not being called.
3. 👎 The problem with the absence of explicit import statements for specific subsets of data is that this de facto becomes an API we can not ever evolve nor change. So, I think it should be tweaked slightly, similar to what we did with XB's internal HTTP API at 📌 Define API URI naming conventions Active : we should version it.

   So instead of:

   drupalSettings?.xbData?.branding?.homeUrl
   

   it should become
   drupalSettings?.xbData?.v0?.branding?.homeUrl

… which will allow for evolvability, backwards compatibility layers, deprecation warnings etc.