Prepare for multiple component types: ComponentTreeStructure should contain Component config entity IDs, not SDC IDs

This blocks #3469610: Prepare for multiple component types: prefix Component config entity IDs with `sdc`.

Yay, thank you, @abhisekmazumdar! 😊

1. No: zero changes are necessary to that. Only docs changes, like this:
   

   diff --git a/src/Plugin/DataType/ComponentTreeStructure.php b/src/Plugin/DataType/ComponentTreeStructure.php
   index afbc656d..7685c241 100644
   --- a/src/Plugin/DataType/ComponentTreeStructure.php
   +++ b/src/Plugin/DataType/ComponentTreeStructure.php
   @@ -56,6 +56,8 @@ use Drupal\Core\TypedData\TypedData;
     * @see \Drupal\experience_builder\Plugin\Validation\Constraint\ComponentTreeStructureConstraintValidator
     * @see \Drupal\Tests\experience_builder\Kernel\DataType\ComponentTreeStructureTest
     *
   + * @phpstan-type ComponentConfigEntityId string
   + *
     * @todo Implement ListInterface because it conceptually fits, but … what does it get us?
     */
    #[DataType(
   @@ -243,7 +245,10 @@ class ComponentTreeStructure extends TypedData {
       * @param string $component_instance_uuid
       *   The UUID of a placed component instance.
       *
   -   * @return string
   +   * @return ComponentConfigEntityId
   +   *   A Component config entity ID.
   +   *
   +   * @see \Drupal\experience_builder\Entity\Component
       */
      public function getComponentId(string $component_instance_uuid): string {
        if (!in_array($component_instance_uuid, $this->getComponentInstanceUuids(), TRUE)) {
   @@ -257,7 +262,7 @@ class ComponentTreeStructure extends TypedData {
      }
    
      /**
   -   * @return array<string>
   +   * @return array<ComponentConfigEntityId>
       */
      public function getComponentIdList(): array {
        return array_values(array_unique(array_column($this->getComponents(), 'component')));
   
   

2. No, it also affects config, in particular: config/optional/field.field.node.article.field_xb_demo.yml. But it's the exact same change, because both content and config are validated by \Drupal\experience_builder\Plugin\Validation\Constraint\ComponentTreeStructureConstraintValidator(). That is the file you'll have to make logic changes in. See the first paragraph of https://wimleers.com/xb-week-12 for context.
3. No, "just" doing that using the UI is impossible until all the code has been updated first 😅 I recommend starting with updating the expectations in ComponentTreeStructureTest to match what I've described in the issue summary.

D'oh, I guess this issue interestingly sits at the intersection of Data model and Config management: it's an update to the data model to correctly use future config management stuff.

Undoing what I did in #4 🙈

🎉 Thank you! :)

This also blocks #3462241: [PP-1] Decorate the SDC plugin manager and allow components defined in code.

#14:

3. That config is not in the MR? You can't just export it though, you'd need to manually modify that default config right now.
4. The only reason that test passes is because you haven't updated the validator yet (next point). 😄
5. This is the crucial next step. 😊

Besides updating the validator, the other crucial next step is to update the logic in the XB field type and the hydrated computed property's logic due to the tree field property now containing component config entity IDs instead of SDC plugin IDs. Did that for you in https://git.drupalcode.org/project/experience_builder/-/merge_requests/2... 👈 Thanks to this commit, as soon as you update the default config (#14.3), everything should render once again. But you probably need to disable the validator temporarily, until you've updated its logic, because that will (should) complain about invalid config.

WRT understanding:

1. These are tightly scoped tests. They test only a single validator. I'm confident you can make sense of them 😊 Tip: the names (keys) of the test cases returned by the provider describe what the test case is testing.
2. I've made one example update to the test cases in https://git.drupalcode.org/project/experience_builder/-/merge_requests/2... — all other test cases must be updated similarly. You can see that this is exactly like the changes to docs/data-model.md. You'll see that now the test starts to fail, so it points to how to validator logic will need to be updated :)

🏓 Back to you — you can do it! 😊

I do totally believe in you! 😄

Also, I very much messed up the sample commits and issue summary 🙈

Issue summary fixed, and mistake rectified on the MR: https://git.drupalcode.org/project/experience_builder/-/merge_requests/2....

Wow those phpcs failures are super weird! 🤪

The first next step: making the phpunit tests pass — they have many failures at the moment: https://git.drupalcode.org/issue/experience_builder-3469609/-/jobs/2697530

Those need to pass first, before the UI will be able to work and before the Cypress E2E tests can possibly pass 😊

Thanks for pushing this forward, I'll take a look at where you got the MR 😊

(Started with merging in upstream, thanks to #3472299: Update default config to make a fresh install result in an XB UI with an empty canvas landing yesterday, this MR now has to make fewer changes, but it required a conflict to be resolved.)

#25 was accurate, yet incomplete: more changes are necessary. The ComponentTreeStructure validator needed to be updated too, for example: https://git.drupalcode.org/project/experience_builder/-/merge_requests/2.... That alone fixes a number of failures.

Done for the day. @abhisekmazumdar, could you push this across the finish line? 😊🙏

Thanks, @longwave!

I think anybody could tackle the remaining feedback :)