FieldType: Support storing component *trees* instead of *lists*

I am taking a look at this

There is a pretty obvious inconsistency in the test data, which is why the scope needs to be expanded to also add test coverage: https://git.drupalcode.org/project/experience_builder/-/merge_requests/6....

Add missing comma to proposed resolution.

1. 🥳 It works! 😄

2. // @todo This is a temporary checks until we have a constraint. Just to make
       //   tests fail if we don't have good test values.
       if (!isset($this->tree[ComponentTreeStructure::ROOT_UUID])) {
         throw new \UnexpectedValueException('Temp exception replace with constraint. Root UUID is missing.');
       }
   

   On a meeting just now I said I was fine with this, but … I now see that the constraint was part of this issue's scope, as mentioned in the issue summary.

   Having actually reviewed the MR, I am now convinced by that even more, because since ✨ Allow specifying default props values when opting an SDC in for XB Fixed landed, we now have strict config schema checking for all tests.

   Having explicit test coverage for this will also allow us to validate the default value in config/optional/field.field.node.article.field_xb_demo.yml — similar to what 📌 Lift most logic out of ComponentTreeItem::preSave() and into a new validation constraint Needs work is doing.

I wrote #9 before I saw 📌 Create validation constraint for ComponentTreeStructure Needs work .

Why don't we merge#3460856 with 📌 Lift most logic out of ComponentTreeItem::preSave() and into a new validation constraint Needs work — i.e. why don't we expand the scope of that? It's exactly the same problem space!

The pipeline https://git.drupalcode.org/project/experience_builder/-/pipelines/222097 says it is "blocked" but I am not sure what is blocked on

I ran all the jobs and it passed

I have no idea how the pages CI job is getting triggered for you 😅🤪 Never had that happen!

This is obviously actually passing all tests.

I just fixed a few nits, and I see the same status as the summary for the overall CI pipeline. That's just GitLab CI being silly/dumb: it's because the pages CI job is the last CI job (in the last stage), and hence that becomes the status/summary.

I think we can get rid of it by removing the manual rule — then it just won't show up for MRs — and that's indeed working: https://git.drupalcode.org/project/experience_builder/-/merge_requests/6... 👍

Automatically closed - issue fixed for 2 weeks with no activity.