Personalization component source

Bumping to because this is what will get us to 100% confidence in answering

1. feature: ability to store variants of component trees for use cases like personalization (i.e. different component subtree for Belgians & Brits vs everyone else), responsive design (i.e. breakpoint-specific overrides), and arbitrary future use cases

penyaskito → credited jessebaker → .

So we've been assuming one component source → one personalization component with dynamic slots.

Somehow I forgot about #3525746-6: Update the React client preview view → , where we agreed that the backend should provide one (maybe 2?) component source(s), that will have 2 component types (with one slot), the switch and the case, in the same way than the client layout model.

It's clear that when rendering the component, for the purpose of this issue we

a) can hard-code the negotiation when rendering a personalization in "live" mode. This will be fixed later in 🌱 [META] Personalization Variation negotiation and rendering Active .
b) need to render all the switch/cases when rendering in "preview" mode. The client will need that for allowing live previews, and its the responsability of the client UI to render the cases based on the "active segment".

For the component "switch", its inputs it's the mapping of segment ⇔ variation. Taking into account that this is a 1:1 relationship for now, but won't be in the future, and could have attributes in this relationship.

For the component "case", there is no inputs. The "switch" mapping inputs above will reference the uuid of the "case".

We might try doing a single component source, where the inputs are not mandatory. But it might need to become two different component sources.

It's clear that when rendering the component, for the purpose of this issue we

+1 to both

We might try doing a single component source, where the inputs are not mandatory. But it might need to become two different component sources.

Let's find out :)

Pushed a sequence of commits that is the result of @penyaskito and I pairing and debugging for ~2.5 hours 🥵😵

Next steps

1. lift 📌 Create recipe with personalization demo Active 's https://git.drupalcode.org/project/experience_builder/-/merge_requests/1... into this MR, and adjust it to no longer use static prop sources — it should become a LOT simpler :D
2. next, write the test coverage (that uses the test/demo module the prior point is adding), that proves the appropriate "case" is rendered: the halloween one if ?campaign_utm_whatever=halloween is in the URL, the default in every other case
3. … and NOT implement generic negotiation logic; that's for later — as far as I'm concerned we can even just do $variant_id = str_contains(\Drupal::request()->getUri(), 'halloween') ? 'halloween' : Segment::DEFAULT_ID; 🤓 We can swap out that logic for something much more advanced in 📌 Implement the Context for Variation and Variation negotiation Postponed 👍

P.S.: for naming variants (i.e. "case" component instances), I propose we use ✨ [PP-2] Allow users to name components for the specific context Postponed . That'd keep the data model here as simple as possible, and would keep the "Human-readable name" part out of this MR.

Forgot something crucial in #9:

⚠️ OUT OF SCOPE: working component instance forms! Step 1 above should just make the sole Page<?code> content entity that <code>xb_personalization_demo is installing inspectable. These 2 new components should NEVER be visible in the list of components to instantiate (but they currently are) and they should NEVER be showing up in the layers menu on the left the way they currently are, but this is a great way of visualizing a known starting point (the xb_personalization_demo module described in #9.2+#9.3) for the UI to be developed against.

IOW: consider this an incomplete yet pragmatic tech demo that enables bootstrapping this functionality 🤓

Updating title. Basically:

• → #9
• → #11

Forgot the GIF I created 🙈

This is where @penyaskito and I got:

This is ready for reviews.

I've done some clean-up, and think this is in a commiteable state.

To notice:

#11 If we ever want to do that we might need a new anonymous class as \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::buildAnonymousFormForBlockPlugin does. Don't think it's worth the effort as this would go away anyway.

We have a recipe now for setting up the automatic/manual test scenarios. See MR description for applying it.
Ideally this would be build on top of `test_site` recipe, but that one's content didn't validate for me locally.
I've added a note on the recipe.yml file about this.

Our e2e test is actually a KernelTest 🎉
We probably want a.playwright test in the future, specially when we have the UI changes, but for now this works and found it overkill here.

Reviewed ~70% of this MR. Remainder tomorrow.

RTBC!

What an epic MR!

One last realization is that the client won't be able to start building the React UI changes in 📌 Update the React client preview view Postponed without also making back-end changes in the same MR — because the BE sending nodeType: switch|case as described by @effulgentsia at #3525746-6: Update the React client preview view → will cause the UI to break immediately, which would've made #13 impossible.

We both realized that it might actually be better to change variant IDs to not be some kind of machine name-esque string, but UUIDs. Not yet implemented here. Thread: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...

About to merge! 🥳

Yay!

Now only the docs MR! 🥳

penyaskito → credited effulgentsia → .

All done! 🎂

I think there aren't any follow-ups needed, so marking as fixed 🎉

Yep! Don't know why I didn't do that 😅