Remove root UUID

It seems like this should be stable blocker decide at least if we want to do this. If we do it is probably better before stable otherwise I think we would have to write an update hook that would update all content entities to use the new structure.

This also relates to 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active : once content type template exists, the following scenario can occur:

1. the XB content type template for "article nodes" has 3 subtrees that are unlocked, i.e. in which content creators can do whatever they want
2. that means the XB field for each article node won't store a single tree anymore (under the root UUID), but 0–3 trees!

ContentTemplate config entities now exist.

✨ Content templates, part 2: store a component tree in the template, and allow individual entities to fill in specific slots in that tree Active is in, and ✨ Content templates, part 3b: store exposed slot subtrees on individual entities Active is being worked on. @phenaproxima, any thoughts on this given you're actively working on #3519352? 😄

Well, at the moment, ✨ Content templates, part 3b: store exposed slot subtrees on individual entities Active uses the root UUID to know what components in a subtree need to be injected directly into an exposed slot, and which components are just added to the main tree.

Having said that, though, what would the tree structure look like if we made this change (how would it represent infinite nesting)? That would help me understand any knock-on effects for exposed slots.

Back to Wim for answers. :)

📌 [PP-1] Consider not storing the ComponentTreeStructure data type as a JSON blob Postponed will likely implicitly address this.

IOW: this will likely be closed. Let's hope. 🤞

When this issue was opened, every component tree in XB was self-contained. But with 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active getting implemented, that will change:
for content entities whose content entity type + bundle has a ContentTemplate, it's possible that each individual content entity does NOT define the full component tree, but only bonsai trees (see ✨ Content templates, part 3b: store exposed slot subtrees on individual entities Active ) to populate the ContentTemplate's exposed slots — aka the "islands of freedom", but the root of the tree would be the same for all content entities.
IOW: the root of the tree would always originate from the ContentTemplate, and each content entity would not store one component tree (starting at the root), but multiple bonsai trees (staring at slot of a component instance in the ContentTemplate's component tree whose slot was explicitly exposed).

In that world, to be able to distinguish where the root begins and ends. For a moment, I thought while reviewing #3468272's MR that we'd need to keep the root UUID. But thanks to ValidParentAndSlotConstraintValidator's logic in that MR, I think we don't! Would be good to have @larowlan confirm :)

I think the front-end is still using it, so we will need to handle that at the same time, but yes, the path to removing it is clearer after that

👍

(Although I don't see how the front end using it is relevant: the client-side data model already is very different from the server-side one. It'd be fine for the client to continue to have such a root UUID. This issue is solely about the server-side data model.)

Reviewing 📌 [PP-1] Consider not storing the ComponentTreeStructure data type as a JSON blob Postponed right now, it 100% certainly addresses this! 🥳

Actually — I'm kinda wrong in my prior comment!

That MR mostly addressed this:

• the root UUID is no longer used in storage (neither for component trees stored in a XB field on a content entity, nor in component trees in config entities) — this is the critical stable-blocking part @tedbow pointed out in #2 👍
• but it is still used when A) hydrating the tree (ComponentTreeItemList::constructDepthFirstGraph()) and hence when rendering, B) when performing the client-to-server conversion

We should still remove it, but it's actually only used internally now; so refactoring it away is essentially a purely internal change 🥳

So: reducing priority, retitling, rescoping.