[later phase] [PP-2] Prepare for multiple component types: prefix Component config entity IDs with `sdc`

Let's hold off on this until #3462241-2: Decorate the SDC plugin manager and allow components defined in code → is clarified (not implemented/complete, just direction finalized). Because the way that is going, this would just not be necessary.

Oops … 🙈

I got this wrong, because I got #3469609 wrong — see #3469609-18: Prepare for multiple component types: ComponentTreeStructure should contain Component config entity IDs, not SDC IDs → .

Fixed now.

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

📌 [PP-1] Add support for Blocks as Components Active is moving forward, and @f.mazeikis confirms we will need this.

For now, this should hardcode sdc+ as the prefix, until 📌 [PP-1] Add support for Blocks as Components Active introduces a constant that can be used instead :)

There is some inconsistency going on, which is the source of the UI breaking.

In ComponentTreeHydrated::getValue() we do

      $sdc_component_plugin_instance = $this->getComponentPluginManager()->find(Component::convertIdToMachineName($component_id));

but $component_id is already a machine name by this point in preview, because that's how it comes from the backend already. But at what point should this be translated? I'm confused about the shape sent by the client and how that gets mutated into the tree and then the render array, and at what points "component ID" means "config entity machine names" versus "SDC ID" - overloading the term and swapping back and forth between the two is very difficult to follow.

#9: yes, the UI's data model is too simplistic right now. That's why we have these in \Drupal\experience_builder\Controller\ApiPreviewController:

• class HardcodedPropsComponentTreeItem
• ::clientLayoutAndModelToXbField()
• ::clientLayoutToServerTree()

Essentially, we have let the UI/client live in a simpler world than the reality, until such a time where we know in more detail what the client will need to know.

For ~2 months now, 🐛 Some components cannot be used in XB because UI prevents SDC props being named `name` Active has served as the "change the client-side data model to be less simplistic" critical bug. I've just rewritten that massively expanded the in that issue's summary.

This issue should not wait for that one. It likely needs to update the aforementioned methods.

#9: I think part of the confusion is coming from 📌 Prepare for multiple component types: ComponentTreeStructure should contain Component config entity IDs, not SDC IDs Fixed not having done everything correctly: I failed to spot in my review there that ::clientLayoutToServerTree() should've been updated too.

Per #3475584-11: [PP-1] Add support for Blocks as Components → , this blocks #3475584.

Tests should be green now.

Opened 📌 Replace plus with dot in component config entity IDs Active to discuss swapping the separator.

Reviewing! Thanks for opening that issue :)

Looks great! Only trivial nits, half of which you identified :D

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