Allow Content Creator to name component instances for the specific context

Fascinating! 🤔

So, do I understand correctly that component instances should not only have a uniquely identifying UUID, but also optionally a user-defined label/contextualization/badge?

If so, important consequences:

1. when using asymmetric translation (see 📌 Allow Experience Builder fields to support Asymmetric and Symmetric translations Needs review ), that badge would not be showing up in the same language as neither the UI nor the content being edited, but in the original language. Unless the badges themselves would be translatable too. But if that's translatable, that would complicate the UX?
2. AFAICT the badge makes sense based on the location in the tree more so than the contents of the components? If so, then the badge should be stored as part of the tree structure (tree → \Drupal\experience_builder\Plugin\DataType\ComponentTreeStructure). Or … if it depends on the contents, then it should be stored as part of the props values for each component in the tree (props → \Drupal\experience_builder\Plugin\DataType\ComponentPropsValues)

IOW: this triggered new data model questions 🤓

Unless the badges themselves would be translatable too. But if that's translatable, that would complicate the UX?

We could make the label translatable. I would imagine the translation would be added just by editing the label within the translation so I'm not sure how that would complicate the UX?

AFAICT the badge makes sense based on the location in the tree more so than the contents of the components? If so, then the badge should be stored as part of the tree structure (tree → \Drupal\experience_builder\Plugin\DataType\ComponentTreeStructure). Or … if it depends on the contents, then it should be stored as part of the props values for each component in the tree (props → \Drupal\experience_builder\Plugin\DataType\ComponentPropsValues)

I'm not sure I understand what would be the implications of storing this in one or another. Could you elaborate on that? 😇

so I'm not sure how that would complicate the UX?

It'd mean this metadata (it's not actual content) would have to be translated too.

The complication is that the UX would have to design/signal in some way that a component badge is not yet translated, and should nudge the content creator to translate it.

I'm not sure I understand what would be the implications of storing this in one or another. Could you elaborate on that? 😇

I was actually only talking about semantics, not implications.

The implications would depend on what choice the Site Builder made wrt translation, see 📌 Allow Experience Builder fields to support Asymmetric and Symmetric translations Needs review . Asymetric translation would mean the components would be different per translation, which would mean there is no need to translate then the component badge.

It'd mean this metadata (it's not actual content) would have to be translated too.

The complication is that the UX would have to design/signal in some way that a component badge is not yet translated, and should nudge the content creator to translate it.

Why do you think there would have to be a nudge to translate it? I see the label merely an enhancement for content authoring. I wouldn't consider it a big deal if it's not translated to the target language because it's not presented to the end-user. However, they should have the option to do that. If a designer created Figma files for different languages, I doubt that they would translate the layer names unless there was a good reason to do so.

I see the label merely an enhancement for content authoring.

I'd find it jarring if everything was in Dutch but the label/badge was in French. Especially if it wasn't marked in a way.

There could be an alternative approach which is to just not display the original label and expect it would have to be set again in the new language. The reason I'd consider this inferior is because if you see the original language, at least you can put it in a translator and come up with a translation.

AFAICT this was blocked on ✨ Component name badge above component preview Active . But I don't think it's blocked on … anything else? 🤔 Except for design!

So: assigning to @lauriii for visibility.

A flaw in the current implementation (which dates back to May, around the very start of the 0.x branch, when there were zero designs still — so it's SUPER COOL that you anticipated this, @jessebaker! 😄) is that it basically reserves name SDC prop name. That means no SDC that uses name as the prop name can work — because name is stored alongside the values for SDC props in the model that is sent to the server for previewing etc.

As of 📌 Create an Open API spec for the current mock HTTP responses Fixed , this problem is also clearly present in the sample response that is in /openapi.yml — the full shape of model is not yet defined in there 😅

@lauriii, when designs are available, please assign this to @jessebaker so he can articulate how he wants to deal with 👆

Discussed with @balintbrews and agreed that we can work on this without designs based on the assumption that the name will be edited inline in place of where the label would be displayed. This can be triggered by double clicking the label, or by choosing "Rename" action from the contextual menu (which is behind right click).

Some screenshots for inspiration:

#10 sounds great! 🤩

Is this in scope for 🌱 Milestone 0.1.0: Experience Builder Demo Active ? If so, please mark it 🙏

Wim Leers → credited balintbrews → .

Crediting @balintbrews per #10.

Attaching the video for reference.

We discussed with @utkarsh_33 that we could enhance this by adding the rename functionality to two more places:

1. As a menu item in the context menu (when you right-click the name tag);
2. The layers list in the left sidebar — with the same double click interaction.

Minor thing, but as per https://www.drupal.org/project/experience_builder/issues/3459249 📌 Allow opening the contextual menu by right clicking a component Needs work it should be possible to right click directly on a component, not just its name label.

I am not sure who is the right person to review this as this is not a priority but it now takes care of

The layers list in the left sidebar — with the same double click interaction.

.
I also added the test for the above scenario.

I think this could still be optimised by moving the common logic between the two components ie:-NameTag and TreeNode and i tried that as well but there was problem when i was editing the name in menubar content.If we need to do that then i might dig more into the problem but if we are ok with the current implementation then it's ready for an initial round of review.

Lots of MRs landed, this now conflicts.

I just realised that we can add another scenario of testing in this MR which clicks the NameTag itself(which is the main feature of this MR) and then edits the name of a component.
But the challenge with that is we don't have unique selectors for buttons and name tags for now.So does it make sense to include those changes in the scope of this issue or shall we create a follow-up which fixes this problem and then we can add the test scenario?

#24:

Because that's inside the preview, the <NameTag> is layered over that 👍

Looking at NameTag.tsx, this doesn't seem too complicated to add? I think it'd be better to solve this more comprehensively, so let's do it here. 🙏

Postponing this pending the decision on 🐛 Some components cannot be used in XB because UI prevents SDC props being named `name` Active and the code changes from 🌱 [Proposal] A different approach to the iFrame preview interactions Active being merged

Updating to [PP-1] as 🌱 [Proposal] A different approach to the iFrame preview interactions Active has now landed!