Add typed value-objects for the component tree structure

This should also allow refactoring 📌 Create validation constraint for ComponentTreeStructure Needs work to make it simpler 👍

Brought in the value objects and a normalizer. Will continue tomorrow

Wim Leers → credited kim.pepper → .

Reviewed! (Review delayed due to 📌 Introduce an example set of representative SDC components; transition from "component list" to "component tree" Fixed , I explained this in my review on the MR.)

Thanks Wim, I'll pick this up again after vacation

👍 Enjoy! 😊

Having introduced the very barebones ClientSideRepresentation object last night in 📌 Improve or remove ComponentSourceInterface::getClientSideInfo() Active , and seeing the existence of both:

• 📌 ServerClientConversionTrait Active  — to complement ClientServerConversionTrait that was introduced in ~2 months ago at [#347856]
• 📌 Add a param converter and DTO for XB data model Active

… makes me realize that you probably just were able to see months into the future with this proposal 😅 🤩

I definitely could not. Not until 📌 Not all components have UUIDs, so rename to ID Active and 📌 Add support for global regions Active had landed, both of which clarified the client-side data model, and it:

• has its rationale documented at docs/adr/0005-Keep-the-front-end-simple.md
• has its structure documented at docs/data-model.md, section

Now that all that is in place (i.e. we know the client-side data model), I can totally see the value of what this MR originally envisioned: the ability to "upcast" any data source into the data model expected by the client, which will allow loading it into the client and then saving it into an XB field.

That means I'm now somewhat disagreeing with point 1 of my August 8 comment at https://git.drupalcode.org/project/experience_builder/-/merge_requests/1.... Although I do still think it'd probably be more powerful/interesting to be able to convert to the server-side data model directly, I'm not sure that that is required or even sensible — because I suspect that we'd never auto-convert "Layout Builder data" to "Experience Builder data", but instead make the transition trivial, while still requiring a human to do so.

Conclusion: I think that what I wrote in August might be the ideal scenario from a migration path POV, but I doubt it's realistic to achieve perfection. To overcome that imperfection, we could require human intervention, which is exactly what your proposal achieves. Thoughts?

The other thing this enables is the BC layer for Paragraphs and Layout builder for 📌 Decouple tree storage, introduce tree storage plugins Active

Because we will need a contract for 'here is an entity, load me a tree for it' and the value object is 'the tree' in that contract.

This will allow us to load legacy layout builder layouts (a subset of what XB supports) and edit them in XB, saving them as XB data - allowing sites to progressively update (one edit at a time).