Personalization component source

• This end-point will receive a set of component UIIDs that needs to wrap
• This end-point will receive a personalization variation ID
• This end-point will change the tree structure wrapping the received components into a "default" personalization variation ID so we can keep the existing defaults
• This end-point will create the grafting of another personalization wrapper for the active personalization variation ID with copies of the previous components

🤔 I'd expect these pieces to happen client-side, and for the client to send that to /xb/api/v0/layout/{entity_type}/{entity} on the server (which will auto-save and respond with an updated preview).

IOW: this would be equivalent to:

• placing a new component instance
• moving an existing component subtree into that component instance

I do not understand why we'd rely on the server side to update the client-side data model, when it's a client-side action that causes the changes.

That would definitely simplify things. I assumed we wanted the client to be dumb about this.

What I had envision would be something like

POST /xb/api/v0/layout/{entity_type}/{entity}/personalize

with { components: {uuid-component-1, uuid-component-2}, variant: my-variant}

And that would encapsulate the same operations you described.

The client already will have to make personalization-specific UI changes. So it'll need to be aware anyway.

I think requiring the client to talk to the server would be *more* complexity and logic. Because it is a simple tree manipulation vs I/O over the network with all complexities that that brings.

Met today with @wim leers, and we reviewed 📌 Replace the postPreview action with atomic equivalents Active and it would really play really nice with the plan at #6 (doing this server side).
That would ensure we can have concurrent editing even when doing personalization, reducing the chances of having race conditions.

However, @mred9 has some progress on doing this as explaining #5 (client-side).

So we are (shortly) postponing the decision here on:

a) Reviews on 📌 Replace the postPreview action with atomic equivalents Active to decide if that's mergeable/close to mergeable and we actually want that before 1.0.
b) Seeing the work @mred9 is doing on the client-side, which will be pushed to a new branch in 📌 Personalization PoC Active

No matter the decision, this will need a IS update now that we know much more.

📌 Replace the postPreview action with atomic equivalents Active is super unlikely to land any time soon, so let's go with the client-side approach that @mred9 already had working!

(Supposedly there is an impressive screencast of this, but I haven't seen it yet 😇)

Not a priority right now, but this is not postponed anymore.