clear_button plugin

[Koloto]

The plugin adds a small cross on the right which clears all items (while remove_button plugin removes only one item).

[coveralls]

Changes Unknown when pulling a5d61d2 on Koloto:clear_button into ** on selectize:master**.

[Koloto]

@brianreavis, @joallard Any chances to merge this PR?

[Pictor13]

clear() will not trigger the 'item_remove' event (see pull request: ea2e931#diff-a1e04fdc9fa0888b83d5b5401328081bR62)

Maybe it is on purpose, but just wanted to mention it, in case deleteSelection() is more appropriate.

[Pictor13]

Actually clear() already triggers the event clear. And that might be enough.

Having the item_remove event being triggered automatically would be just convenience; probably one should listen on("clear item_remove") in case of wanting to execute the same callback for both events.
E.g. using the same callback for settings onClear and onItemRemove will achieve that.

Additionally, deleteSelection provides support for the onDelete callback, that is an actual useful feature (validate values before removal and eventually prevent the clear/remove operation).
I believe this should be still supported also when clearing or removing items (so that we can stick to what said in the previous paragraph).

[Pictor13]

• I added a comment to the code, about the use of clear method (a5d61d2#r129585962). Just in case..
• Also I am not sure about the reason for changing the selectize.js source (a5d61d2#diff-6cee306935e9c39b0f577d4ccb04fadeR1814).

Except for that: thank you for the plugin :)

[Koloto]

@Pictor13

• deleteSelection() removes the selected items only, not all. You can select an item by clicking on it (in multi mode), then it will be marked with active CSS class. I think clear method should be changed to trigger item_remove event.
• Changes in selectize.js are required to prevent deleting clear button itself.

[Pictor13]

• Regarding the selectize.js change, are you sure it is safe?
  I didn't check, but I was thinking that putting the button inside selectize.$wrapper could make more sense, and would prevent from touching the library code (plugins should serve that purpose).
  Just a suggestion of course. If it doesn't break any use case then your change is totally fine.

• About the item_remove event I wondered the same; but I was focus on fixing the remove_button plug-in and I didn't investigate further, taking for granted the bug was in the plugin and not in the main library (evil assumptions...).
  I wonder if my pull request is wrong then, in relying on deleteSelection() for both modes (single/multi). It was the only way I could get all the expected behaviours (and the events triggering).
  But I have to admit it felt like a hack to make it work that way; while maybe the fix of clear() is the right thing to do here, as you wrote.

Also, feel free to comment back my pull request, if you think is wrong! 👍

[Pictor13]

I would add some insights (useful for my pull request and for this one as well), coming from reading code and tracing the commit history:

There are some evidences, in the repo history, that deleteSelection() is adequate for removing items in any situation (in fact it is what's being called, regardless the mode when pressing DELETE/BACKSPACE.
In general selection won't be available via UI but can still be set programmatically and is not incompatible with, e.g., single mode.

Also, deleteSelection supports the onDelete callback (the only way in the library to validate values and prevent deletion/removal), while clear/removeItem don't take that in account.
I believe this to be an incongruence, since specifying an onDelete callback is a feature that should always be available, rather than being called exclusively in multi mode or in a context of a selection.

Note: this is not directly related to this pull request, but I wanted to leave a trace for when the above mentioned details will be implemented/fixed.

[github-actions]

Stale pull request message