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.