`ComponentTreeStructure` data type: simplify the stored structure

Wim Leers → credited longwave → .

And after this lands, an intriguing potential next step is possible:

8. As a content creator, I want to edit meta fields directly within the page builder interface. For example, the menu links and URL alias should be editable on the same page as the page builder.
9. As a content creator, I want to edit fields directly within the page builder interface. For example, the title should be editable on the same page as the page builder. I expect the page title to be displayed in the preview.

should both be covered by this; with the widgets for all of the entity fields (except for the XB field) appearing in the right sidebar, and hence in a single form. IOW: everything in the default form mode/display.

But the implementation should allow specifying a form mode, to allow in the future requesting only the meta fields (TBD how to identify these: 📌 [later phase] [RESEARCH] How to identify all meta fields for an arbitrary content entity? Active ), or only the "structured data" fields.

LOL, changed issue metadata on the wrong issue 🤪 — that was intended for #3463988-6: HTTP API: new /xb/api/entity-form/{form_mode} route to load form for editing entity fields (meta + non-meta) → .

This seems like a good idea but I would like to look at how it simplifies, hopefully, the code we already have.

I have updated the sample structure in the issue summary because I think it was missing component information for component that were at the tip of the branches. At the end of each tree branch that will have components that either have no slots, only properties, or have slots that don't components in them.

For example uuid-root-3 and uuid4-author3 had no component specified

I think we should do 📌 Convert test cases to use php arrays instead of json strings where possible Needs review first otherwise the reviewer will be having to review a lot of 1 line long json strings

📌 Convert test cases to use php arrays instead of json strings where possible Needs review is in.

This is still very much worth doing. 📌 Prepare for multiple component types: ComponentTreeStructure should contain Component config entity IDs, not SDC IDs Fixed landed last week, and this would be another step in the right direction on the data model front 🙏

Fixing tag

Having a go at the reroll and fixing the pipeline errors, at Drupalcon Barcelona.

Updated MR with latest changes and fixed phpcs violations. Getting the tests green was a bit of a stretch for me. I'm leaving that for anyone with more knowledge of the expierence builder itself.

Thanks, Stef! 😊

Next steps here:

1. Update the sample JSON blob in section 3.2.2 The `field prop` storing the props values of docs/data-model.md as described in the issue summary.
2. Update the props JSON blob in /tests/modules/xb_test_config_node_article/config/install/field.field.node.article.field_xb_test.yml, that will fix a bunch of test failures.
3. Then, the lowest-level tests that fails (and hence should be fixed first) is ComponentTreeStructureTest::testValidation().

@stefdewa I hope you don't mind that I tried to spend some time moving this forward with @wim leers' input.

I also made an oopsie and added an unwanted commit to it, which I undid and fixed.

Added a new commit for the docs/data-model.md changes. I hope thats correct changes.

Now I want to understand how can I create a correct format props JSON blob for /tests/modules/xb_test_config_node_article/config/install/field.field.node.article.field_xb_test.yml

Then maybe eventually I can fix the other broken test cases.

Yep, looks good, keep going! 😄