Provide another example of Copy on drag

[mutil]

Hello and thanks for this wonderful library!

I try to modify the Copy on drag example to suit my use-case but I had no luck so far. Basically, I want to be able to move the items inside the Dragula-like list and only copy to another drop zone. The first example allows copying inside the list and the second one prevents moving items inside that list.

At some point I encountered the errors described in #469 when dragging back and forth the item over the lists (without dropping).

To simplify it a bit, think of a predefined list where you can only sort the items (no add/remove/copy inside) and a different drop zone which accepts an item from the list.

It would be nice if you could add a REPL with this functionality (drop-only example). Thank you in advance.

[isaacHagoel]

I am trying to understand the requirements. Can you describe it in a more structured way? For example:

1. the are two lists: list A and list B
2. in list A:
   • you can sort the items
   • you cannot drop items from list B
   • please explain how you want copying to work, when does the copy get created? sounds like not on drag start
3. in list B:
   • you can sort the items
   • you can drop items from list A

[mutil]

• there are two elements: list and widget (a list with only one item)
• in list:
  • you can sort the items
  • you cannot drop items from elsewhere
  • you cannot remove items
  • you can copy selected item to widget
• in widget:
  • you can drop item from list (it will replace the current one)

[isaacHagoel]

What is the timing of the copying? On drop or on drag start?

On Thu, Dec 21, 2023, 09:44 mutil @.***> wrote:

1. there are two elements: list and widget (a list with only one item)
2. in list: ◦ you can sort the items ◦ you cannot drop items from elsewhere ◦ you cannot remove items ◦ you can copy selected item to widget
3. in widget: ◦ you can drop item from list (it will replace the current one)

— Reply to this email directly, view it on GitHub https://github.com/isaacHagoel/svelte-dnd-action/issues/530#issuecomment-1865240630, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE4OZC742H4IIL532PATFF3YKNS33AVCNFSM6AAAAABA5IAGPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRVGI2DANRTGA . You are receiving this because you commented.Message ID: @.***>

[mutil]

On drop

[isaacHagoel]

Doable. I will should have an example ready by tomorrow

On Thu, Dec 21, 2023, 11:38 mutil @.***> wrote:

On drop

— Reply to this email directly, view it on GitHub https://github.com/isaacHagoel/svelte-dnd-action/issues/530#issuecomment-1865318691, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE4OZC3X5V4HCS7F2437MZTYKOAIPAVCNFSM6AAAAABA5IAGPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRVGMYTQNRZGE . You are receiving this because you commented.Message ID: @.***>

[isaacHagoel]

i have an example but there is still an issue with it that happens if when dropping anything but the "I" into the widget and will be resolved when #533 is merged.

[isaacHagoel]

@mutil check out the example (link above and in the README). Let me know if you have any questions or if it is not what you intended in some way. Closing this issue (feel free to re-open if needed)

[mutil]

The example works fine, although I think it can be simplified (no need for extra events and props) [simplified REPL].

One minor annoyance is that when the dragged item is hovered over the widget, the list items reorder (as if it was about to move out of list). Ideally, list items should stay in place like when the item is dragged outside of any zone.

Anyway, now it works for my use-case, thank you again.

[isaacHagoel]

Hi, The simplified version you provided violates one of the "rules" of the lib (see README)

The host component must refresh the items that are passed in to the custom-action when receiving consider and finalize events (do not omit any handler).

The consider handler in the widget doesn't update the lib (doesn't re-assign anything to the item). It does happen to work in this cashe which is super cool :) but I can't guarantee that it will keep working in all future versions. A slightly different implementation in which the widget accepts the new item on consider would remove the need for the prop.

Regarding the second point, in general the lib will show you when the item is going to be dropped by making room for it. In this case only the list does it (so when the element is outside of both it makes room to land in when dropped). You can change this behaviour by adding an "order" property to the list similarly to this example from the README.

   e.detail.items.sort((itemA, itemB) => itemA.order - itemB.order);
   items = e.detail.items; 

[isaacHagoel]

Actually thinking about it again the unsortable list doesn't address your concern (sorry I just woke up. lol), but it still illustrates the idea of not just accepting what the lib tells you. You can also do other things such as create the copy when the draggable enters the widget and removing it if it leaves or all sorts of other behaviours as you see fit.