Expose internal select2 settings

[iStefo]

As described in https://github.com/iStefo/ember-select-2/pull/23, there is a need for accessing the full flexibility of the jQuery select2 plugin, that can not be established in the near future when trying to uphold the current quality and safety of this component.

I explained why I think that simply opening every option to the outside world is not a good idea: Because it may give the illusion that every setting is tested and works the way things work in ember.js. But they might not, and opting-in should be harder than just setting a binding - but not as hard as forking this project!

Therefore I am thinking of a way that does not require modifying this code, but maybe instead subclassing it. A very early idea would be an API like this:

import Select2 from 'ember-select-2';

export default Select2.extend({
    // define options here for all instances of this component
    customOptions: {},

    // or in a dynamic fashion based on custom options from outside
    customSetup: function() {
        this.customOptions = {
            matcher: function(...) { /* custom plain-JS matcher to override provided */ },
            otherSelect2Setting: true
        };
    }.on('init')
});

When setting up the component, ember-select-2 could check the customOptions (not calling it options on purpose) hash and choose the options provided there over the default implementations. This way, all the flexibility is exposed but no false promise is made for compatibility.

An alternative approach would a an optional method that would be called after building up the original options hash and that works like this:

import Select2 from 'ember-select-2';

export default Select2.extend({
    customizeOptions: function(options) {
        // override options while having access to the defaults
        var oldMatcher = options.matcher;
        options.matcher = function(item, query) {
            // allow items that match the query and all superstar items
            return oldMatcher(item, query) || item.superstar;
        }
        return options;
    }
});

This approach seems even more flexible to me because it allows access not only to the select2 default options set by the original component, but also to internal state & configuration that was built up in the didInsertElement method.

What do you think of these two approaches?

[jcope2013]

what is the status on this? would be nice to have

[acorncom]

@iStefo I'm inclined toward the second option myself, as the ability to specify custom options seems to be something that a number of folks will start wanting down the road. As far as your though option 1

no false promise is made for compatibility

Seems like you could state clearly in the docs that customizeOptions has the potential for breakage, use at your own risk and setup tests to ensure things keep working ... Thoughts?

I'm about to add some customizations of my own, which is why I've been looking at this further :-) Would be happy to bounce ideas around on this if it'd be helpful ...

[jniechcial]

I consider second approach as better. I am pretty sure that such opportunity will break select2 in some cases, but as @acorncom said if you make it clear in docs I am sure it will give added value in future. Let us know what's the status on that. If you need any help in coding due to lack of time just give a sign :)

[acorncom]

@iStefo Agreed with @jniechcial, if you want other folks doing the work and sending PRs, we're happy to, just would rather keep all our changes in one place instead of having them spread across custom forks :-)

[NotSqrt]

:+1: Would be happy to see this implemented !

I've seen the following fork implementing related things: https://github.com/qianthinking/ember-select-2 Any other examples that I could build upon in the mean time ?

[jniechcial]

I made it the same way in my custom fork. It is completly enough for per project use, but the extensive implementation should be able to access every option of select2. I like the one that @iStefo present, but until it is implemented still need to work on my own fork to be flexible ;)