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 :)