Fix inconsistency when component is removed on drop #119
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If a drop action causes the draggable component instance to be
destroyed, the dragEnd event isn't fired, resulting in the
dragCoordinator being left in an inconsistent state (it thinks the
object is still being dragged). This change ensures the dragCoordinator
state gets cleaned up before the draggable-object is destroyed.
Note that this fix still won't result in the dragEndHook or dragEndAction
being fired: both of them are still only triggered if a browser dragEnd
event fires. It's not clear if they can be caused to fire in this
case without breaking the API, since both take the dragEnd event
as a parameter, which doesn't exist in this case.
This seems fine for dragEndHook, since it appears to mostly be used for DOM
changes/cleanup and this section of the DOM is going away, but it feels a
bit strange that dragEndAction wouldn't be fired.
Two possible options:
Related to #118