Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disabled items should not be selectable #99

Open
cdata opened this issue Jan 27, 2016 · 6 comments
Open

Disabled items should not be selectable #99

cdata opened this issue Jan 27, 2016 · 6 comments

Comments

@cdata
Copy link
Contributor

cdata commented Jan 27, 2016

When calling methods on selectable elements, it should be possible to exclude disabled items from being selectable.

User story:

I'm looking to change the tabs within a paper-tabs element, so for example based on a property I only want to show a few of the tabs. I use element.selectNext() quite frequently and I noticed that hiding a tab is not enough for it not to be selected.

@bicknellr
Copy link
Contributor

I think it's reasonable to check for an item's disabled property / attribute in _itemActivate and bail out if set, but I don't think we should prevent selection through the API.

Maybe we should expose the _xToY internal functions? (And the function that checks if an item is 'disabled', if added.) This might make it easier to map between items / values / indices and implement this logic externally. Particularly problematic: we expose .items (giving the array of selectable nodes) and .select(value) (which takes the value to select) but not _valueForItem. This means that you can't use the same logic IronSelectableBehavior does internally to determine the value to pass to .select(value). So, as a user of IronSelectableBehavior's API, you have to duplicate this logic yourself somewhere, but this logic can change without notice because it's 'protected'!

@Zecat
Copy link

Zecat commented Aug 6, 2016

+1
It's a common case to have disabled items in a selectable list e.g. IronMenuBehavior.

Sorry @bicknellr I don't really understand what you say in your 2nd paragraph so I'll talk about the first one. _itemActivate is only triggered when activateEvent is received. So if the selection happens because of a method or a change of selectedattribute, the disabled check will be ignored.

_updateSelected seems to me a better place to do the check.

Changing

observers: [
  
  '_updateSelected(selected)',
  
],

to

selected: {
  type: String,
  notify: true,
  observer: `_updateSelected`
},

That way, _updateSelected would know the previous value of selected and reset it if necessary according to the check.

Also, we would need two new methods, to select the previous and next non-disabled item.

@MartonEstok
Copy link

+1

2 similar comments
@ronnyroeller
Copy link
Contributor

+1

@PPCM
Copy link

PPCM commented Nov 10, 2017

+1

@benesjan
Copy link

+25.482631586

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants