Support option with disabled property

[markselby9]

1, Add support for options with disabled property
2, Add corresponding test case and demo

issue reference: #104

[markselby9]

#116

[closuresandcoffee]

This is great. +1 for merging this request.

[sagalbot]

@markselby9 thanks for the contribution!

I think this is an important feature, but the implementation needs to be a bit more abstract. The component needs to remain as agnostic of the data source as possible. Perhaps there are options that need to be disabled, but the disabled key doesn't exist on their data, and they're unable to modify it. Similar to the label prop, you need to be able to define your own key for disabled.

[markselby9]

@sagalbot
I've added an 'disabledkey' for the user to define their own key for disabled, along with test cases and demo.
Thanks for your tips, it's simple and clear 👍

[bcreeves]

Any timeline for when this gets merged and released?

[Anatakun]

Same question : When will this be available ?
I need this for a project, so i'll fork if needed, but it seems i'm not thinking it's really useful and nearly merged into the master.
Thx

[r3cha]

@sagalbot Do you need any help with merge this in master branch?

[r3cha]

To anybody that need to use this feature I create fork and merge this pull request.
Works good, thanks @markselby9
@sagalbot may be create some branch with fast forward accepted new features that we can test it on live projects and make feedback?

[noahduncan]

I'd also love to see this feature merged. Could use it right now! :)

[Phoxloxley]

Has anyone looked at this merge conflict recently? This is a useful feature, I hate to see issues in PRgatory. Also it is Hacktoberfest right now, this could help resolve this easily.

[r3cha]

Here is I merge it
r3cha#1 in my fork, but probably current master at main repo is ahed of mine, because I did it more than 6 month ago

[reppair]

@sagalbot any chance this gets merged soon? It is an useful feature.

[r3cha]

@sagalbot any chance this gets merged soon? It is an useful feature.

It was in 2018 :(
Probably he didn't have time for this

[sagalbot]

Sorry for the long wait on this one, it's definitely one that should get in. The most recent changes are definitely a step in the right direction.

For v3, I've removed the index string prop #800 that allowed you to return an object key to v-model, replacing it with a reduce Function prop that allows you to transform an object (or primitive) however you need before passing it to the input event.

Thinking more about this, I think the best option is perhaps a single Function prop, maybe named selectable. By default, it'd be essentially a no-op function that returns true.

      selectable: {
        type: Function,
        default: option => true,
      },

This function would determine wether the select() method is bound to an option on click, and add a vs__option--disabled class to the item in the list.

Internally, this function would always be evaluated as a boolean. This provides a pretty basic, but powerful API. If your data set happens to have a disabled key, you'd implement as such:

<v-select :selectable="option => ! option.disabled" />

It's only a few more words to type than specifying an object key, but it'd also support more complex situations. For example, a list of people that you can select. In this case, you should only be able to select people that are above the age of 20.

<v-select :selectable="person => person.age >= 20" />

Or perhaps your disable key is deeply nested in an object:

<v-select :selectable="option => ! option.meta.isDisabled" />

It would also work with primitives:

<v-select :options="[1,2,3,4,5]" :selectable="num => num < 3" />

This approach means that vue-select makes zero assumptions about the source data, and works with both objects and primitive options. It is a slightly more complex API than simply providing a string, but is significantly more flexible.

[sagalbot]

Related: #803

[doits]

:selectable feels good to me! Is there a timeline when this will be implemented?

[alxgb]

Agree that the :selectable API sounds pretty good, and considering this is a base feature of a browser select, it should definitely be in the library!

[huglester]

any progress on this?

[wilian746]

any progress on this? @sagalbot pliss?

[doits]

@wilian746 see #921 for an initial implementation - feel free to test and report back your findings (must run yarn build though to have it compiled in dist folder - see #921 for instructions how to test it)

[sagalbot]

Closing in favor of the selectable prop in #921. Will be released in 3.3!