In single selection, polymer-select event should fire once per selection change

[JanMiksovsky]

Currently, selecting an item on a <polymer-selection> triggers two discrete polymer-select events: one for deselecting the previously-selected item, and another for selecting the new item. To me, at least, this was counter-intuitive — I was expecting a single event.

I'd had code that needed to update when the selection changed, and sinking polymer-select caused the code to be invoked twice. I eventually worked out that my handler needed to check event.detail.isSelected to determine whether it was handling the deselection (which I didn't care about) or the selection (which I did).

I'd hazard that most UIs that need to track the selection state (e.g., to show details for a selected item) would want to do the same thing. So I thought it'd be nicer if the polymer-selection were smart enough to just fire the event once, at least for the common single-selection (not multi) case.

There's an existing comment in setItemSelected about replacing the current event with summary notifications. Perhaps that would address this issue, but even if that isn't pursued, it'd be nice to just fire a single event in this common case.

[sjmiles]

Yes, I see how this is potentially confusing.

Fwiw, there are more uses cases than the one you describe. E.g., the selectors support multiple selection, where elements can come and go from the selection list without being in matched pairs. [Edit: ok, I see you considered this and put for 'single selection' in the issue title.]

Initially we had two separate events, but it became onerous to have to listen to two events, and it was simpler to have a single 'selection state changed for item' event.

Maybe there is a way to make everybody happy, will have to cogitate on it.

[JanMiksovsky]

I agree there's a lot to consider here. As you're thinking about this, here's some more food for thought:

• In my experience, scenarios with single-selection tend to vastly outnumber scenarios with multiple-selection. Mutli-selection is something of a pain to both design and code for: not only do you have the mechanics of multi-selection to deal with, you also generally have complex UI state that's dependent upon the selection. Maybe you have a list of email messages, and there are some commands (Reply, perhaps) that can't be applied to mutliple messages, so those need to get disabled depending on what's selected. For these reasons, apps generally reserve the hard work of supporting multi-selection on their main, centerpiece UI: the inbox, the file manager, etc. For everything else (lists in settings, tabs, menus, etc.), apps generally make users deal with things one at a time. I'm guessing that, of all the list-like things in UIs today, something like 90% of them are single-selection lists. If that's correct, the API for polymer-select feels optimized for the 10% case.
• From a user model point of view, in single-selection lists, switching the selection from one item to another is perceived as a single act — the user doesn't perceive a click in a list as deselecting one thing and selecting another. Instead, they just perceive the selection as having switched to a new item. Perhaps that's why, when I was trying to use this polymer-select event (without documentation), my instinct was to assume the event would be fired once for each user selection act.
• I can't think of many single-selection cases where I'd want to do something special when a particular item becomes deselected. The most common would be to revert the visible appearance of the previously-selected item to the normal appearance, but that can be handled be just removing the .polymer-selected style handling the deselection through code. I might want to do something when there's no selection, but that's slightly different; I don't care about which item was last selected, all I care about is that there's no longer a selection. Suppose I have a button next to a list that should be enabled only when there's a selection in the list. The way things stand with polymer-select now, the simplest way to handle that would be to disable the button whenever an item is deselected (because maybe I don't know if a new item is going to become selected), and re-enable it whenever a new item is selected. That feels kind of janky; whenever the user clicks a different item, the button gets disabled and immediately re-enabled. In that situation, I'd rather just hear about the new item that's been selected — and be told the newly-selected item is "null" if the list has completely lost its selection.

Anyway, I appreciate the complexity here. Just sharing some thoughts.