[6.x] Ability to drag and drop between replicators

[jacksleight]

Update of https://github.com/statamic/cms/pull/10361 for v6.

https://github.com/user-attachments/assets/bf23b385-004c-4ff4-8abd-3848d54e72d1

Issues

There are a couple of issues with this in v6 that I've not yet figured out (help appreciated):

• Set preview data seems to work differently in v6, the previews prop and updateSetPreviews methods no longer exist, so I've had to remove those calls. This means that previews get out of sync (wrong index) when you move a set from one replicator to another.
• There are some UI spacing/margin inconsistencies between sets after they've been moved.

Additionally, the previous version relied on the closestVm function to track linked Vue components and allow replicators to talk to each other. This function no longer works in Vue 3 and I couldn't figure out how to make it work, so instead I changed the approach to have the sortable list component keep track of the related Vue components (lists var and owner prop). This doesn't feel like a very elegant solution (neither did closestVm), but I'm not sure how else to do it given the limitations of Shopfiy sortable.

All notes and other changes from the previous PR also apply, except the not-allowed cursors which I've left out to simplify things and minimise UI changes.

[godismyjudge95]

Glad you are resubmitting this; I was really looking forward to it being merged in 5.x :)

Set preview data seems to work differently in v6, the previews prop and updateSetPreviews methods no longer exist, so I've had to remove those calls. This means that previews get out of sync (wrong index) when you move a set from one replicator to another.

I bet the you could use the same approach as what I did for the errors: https://github.com/statamic/cms/pull/11992 Specifically: https://github.com/statamic/cms/blob/master/resources/js/components/ui/Publish/Field.vue#L73-L78 https://github.com/statamic/cms/blob/master/resources/js/components/fieldtypes/replicator/Replicator.vue#L299-L318

I mapped all the errors on first load to their set id so that they'd follow the set around. I think you could do the same for the previews.

[daun]

Amazing 🥬 Thanks for working on this.

One thing I've been wondering is whether this should be opt-in to avoid surprises, with e.g. a group config to control the fields between which shared sets will work. That would allow explicitly linking instances. Imagining a scenario where there's two identical text set types between otherwise completely unrelated replicators. As an editor, I would find it confusing that I can move exactly one type of set and none of the others. Explicit linking/grouping would avoid that.

[jacksleight]

One thing I've been wondering is whether this should be opt-in to avoid surprises, with e.g. a group config to control the fields between which shared sets will work. That would allow explicitly linking instances. Imaging a scenario where there's two identical text set types between otherwise completely unrelated replicators. As an editor, I would find it confusing that I can move exactly one type of set and none of the others. Explicit linking/grouping would avoid that.

That's not a bad shout. Right now you can enforce that with careful set handle naming, but if you have different replicators with identical "item" sets for example things could get mixed up. Happy to look at options, whether it's just making this opt-in per replicator or something more granular like specific group names. Will see what the core team think.