Hey @simonwep I've created this small PR #239 removing the block I found was blocking the events from being triggered.

I managed to test it locally by building and installing the local version.

Please let me know what you think.

Hey @carlos-algms, thank's for the elaborate issue and reproduction! But I'm a little bit confused, because if it wouldn't emit the move and stop events even the simplest selections wouldn't work. I tried it locally and all events seemed to be triggered correctly:

Also in your codesandbox you do a lot with timeouts inside of the callbacks, accessing the values after the might have been changed again by viselect. Could you elaborate what you believe is the issue here? Is it that you would expect stored to be empty if it's also listed in changed.removed in the stop event?

Hey, thanks for investigating it 😊.

The stop event you see comes from the clearSelection() call, not from the unselect().

{
  "added": [],
  "removed": [
    "A"
  ],
  "stored": [
    "A"  // note even tho it was removed, it's still included here.
  ]
}

and it should be

{
  "added": [],
  "removed": [
    "A"
  ],
  "stored": [] // I'd expect it to be empty, as it is the last event I'll receive.
}

I put a timeout there to check the internal state is updated after some time, and stored will be empty, but not on the last stop event.

Aaah, I see! I get why this might be confusing and I'd really like to change it. Even though this is not expected, it's a somewhat "minor" breaking change. I'll have to have a closer look at it to not break anything else (back then I didn't set up E2E tests so any change to such a core thing is critical). I'm currently on vacation but will have a look at it! Thank you again for your clarification :)