Send the onTagRemove event after the single input field has been updated so its easy to grab the new set of tags as a set.
Send the onTagRemove event after the single input field has been upda…
…ted so its easy to grab the new set of tags as a set.
I don't think I'm going to pull this, sorry -- in the docs, onTagRemoved has been used to mean that a tag is about to be removed, not that it already has.
I can see that it'd be useful to be able to hook into both the before and after events. So I think a better idea would be to deprecate this event, and add two new events with clearer names -- something like beforeTagRemoved and afterTagRemoved (perhaps there's a more idiomatic naming scheme for jQuery stuff than this).
The events are inconsistent in your master. onTagRemoved is fired before the field is updated and onTagAdded is fired after. My version is consistent. Sure you don't want to pull it?
Alternatively, how about adding 2 more custom parameters to the event. The field values before and after the update. (I'll do this if you agree its a good idea.)
Ah, the onTagAdded behavior is a bug then. Let me see if that's always been the behavior or not before changing the code or the docs... I recently became the maintainer of this widget, so there are a lot of users of the old version that I'd like to help upgrade without changing much of the API on them.
Because of the legacy support, I'd rather just deprecate this and add 2 clearer events. I'd rather keep them separate than use a data field to specify before/after, since it's potentially a little confusing to generate 2 "onTagRemoved" events per tag removal.
Please see this new issue: #5