danielgindi
commented
6 years ago Yes actually.
The big issue is with nested lists.
You would expect e.preventDefault to solve the issue, or the stopPropagation, but these are two sides of the same problem.
When you have list, where items must be clickable (there are other listeners for mousedown/up) - the inherent .stopPropagation() destroys that ability. So that must be configurable.
And on the other hand, if you do allow propagation - then e.preventDefault won't prevent the events from being triggered for the outer list (beforereordered), where the conditional logic will tell it "it's not ours, abort", and it will abort for the inner list too.
DOM events are not a good mechanism for complex cases like these. The one way bubbling from innermost elements to the outermost does not allow you to properly handle events on both sides. One side will always be "stronger" than the other and will defeat it. While in these cases you want a dead simple callback for the logic, that no one else can interfere with, and you know who sent it.
The intention of the library is to integrate with DOM. It uses DOM as its interface, as tries to be as close as possible to being a native HTML functionality.
This PR adds new non-DOM callback and removes a standard DOM behavior, so I'm very skeptical about this. Is there a strong use case for this that can't be achieved any other way?