You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been working pretty hard over the last few days to add multiple container types to my app, and have had to review all the drag and drop code, and get pretty well-acquainted with the particulars of your lib!
The "drop outside" issue is still the one that requires workarounds.
Approach
Right now, my approach is:
use should-accept-drop in place of group-name for all containers
wrap should-accept-drop and drop handlers with decorator functions that "count in" and "count out" the number of containers that are participating in drops; this allows me to know when there are no more drops left (see below)
in the drop decorator, I return a modified event which:
flags if all drops have completed
provides the "action":
add
remove
order: addedIndex + removedIndex in same container
move: all drops completed, and addedIndex + removedIndex in different containers
dropout: all drops completed, and only removedIndex was detected
Whilst this is working well, it's quite a lot of extra work.
EDIT: have realised I can probably use @drag-enter and @drag-leave events to track the "dragged outside" state (rather than counting in and out) which should allow me to return the flag as per below. It's two more wrapped calls per container-set to store it globally, but should be good enough for a POC.
Proposals
Having really gotten my head into the code + processes, I propose a couple of approaches:
Add a new property to the DropEvent
With only the removedIndex to indicate to the application that a child was removed, we need some additional information to know that it will not be added elsewhere.
Hey @kutlugsahin,
I've been working pretty hard over the last few days to add multiple container types to my app, and have had to review all the drag and drop code, and get pretty well-acquainted with the particulars of your lib!
The "drop outside" issue is still the one that requires workarounds.
Approach
Right now, my approach is:
should-accept-drop
in place ofgroup-name
for all containersshould-accept-drop
anddrop
handlers with decorator functions that "count in" and "count out" the number of containers that are participating in drops; this allows me to know when there are no more drops left (see below)add
remove
order
:addedIndex
+removedIndex
in same containermove
: all drops completed, andaddedIndex
+removedIndex
in different containersdropout
: all drops completed, and onlyremovedIndex
was detectedWhilst this is working well, it's quite a lot of extra work.
EDIT: have realised I can probably use
@drag-enter
and@drag-leave
events to track the "dragged outside" state (rather than counting in and out) which should allow me to return the flag as per below. It's two more wrapped calls per container-set to store it globally, but should be good enough for a POC.Proposals
Having really gotten my head into the code + processes, I propose a couple of approaches:
Add a new property to the
DropEvent
With only the
removedIndex
to indicate to the application that a child was removed, we need some additional information to know that it will not be added elsewhere.I suggest a new property:
The developer can then handle this appropriately:
Add a new handler callback
The other option would be to add a new handler, which would fire only once, and only when all drops are complete:
Wrap up
I think my proposals should be pretty straightforward, and would hopefully mean I could ditch most of my workaround code.
What do you think?
The text was updated successfully, but these errors were encountered: