Previously, if you called e.preventDefault() in a slip:swipe handler, in addition to animating the element back to zero, it would also call slip:cancelswipe. However, this is unintuitive, and error-prone for most uses. It seems to me that after slip:beforeswipe, only one of slip:swipe or slip:cancelswipe should be fired. There was no way to know that slip:cancelswipe was being fired for this reason, and not because it was actually cancelled (i.e. the user let go without actually swiping left or right).
Until making this fix, I had to add some ugly workarounds and flags in all my code that used slip.js and depended on the slip:cancelswipe event.
kornelski
commented
8 years ago
Previously, if you called
e.preventDefault()in aslip:swipehandler, in addition to animating the element back to zero, it would also callslip:cancelswipe. However, this is unintuitive, and error-prone for most uses. It seems to me that afterslip:beforeswipe, only one ofslip:swipeorslip:cancelswipeshould be fired. There was no way to know thatslip:cancelswipewas being fired for this reason, and not because it was actually cancelled (i.e. the user let go without actually swiping left or right).Until making this fix, I had to add some ugly workarounds and flags in all my code that used slip.js and depended on the
slip:cancelswipeevent.