So I think @boneskull once said he was going to rewrite this module and I was like "Awesome! Just make sure it does x and y and z and a and b and c and d ..." to which he was like... "Yeah... nevermind" heh.

So this directive is tricky because it's VERY async. There are a bunch of async 'points of entry'.

When the template renders, to prevent the plugin from creating DOM and disrupting the template, the setup function is deferred. All other async behaviors (option-changes) can't execute until this one has.
The list of available choices may come in late (async) instead of when the page loads
The options may come in late (going from plugin defaults to your app defaults to ajax-loaded defaults, or just watching options for changes)
The default or preselected value may come in late
The value may be changed programmatically (by updating the model)
The value may be changed via interaction (by clicking on select2)

Keep in mind that since ANY of these can come in at ANY order, it makes things complicated. For example, lets say the page loads with the default or initial value, which is an id, or multiple, but you don't have the list of choices. This was in fact why I personally added the initSelection feature to select2.

There are also issues around what format the data you're working with should be in. For instance, we could work with simple string ids, and when multiple is enabled, you have 1 string with a comma-separated list. But when you're working with richer information, you may have entire objects (and not just the id property) or an array of objects. So things get confusing because you're trying to figure out if / when to have a string id, an object, a string of comma-separated ids, an array of string ids, an array of objects, etc.

This is also slightly further complicated by how select2 handles values. For instance, with <select multiple> you would more likely be dealing with an actual array, however in some scenarios, this is not what select2 does. He uses an <input type=hidden> when he expects you to programmatically add options (instead of changing the <option> list). Now, this is actually a GOOD design point, because it means if you load 400 options, we don't have to keep the DOM in sync, and improves performance. But the catch is that <input> doesn't natively handle arrays. Also, I didn't know about ng-list when I was building this directive.

There's also issues when setting the value programmatically. When you work with an array of rich objects, and someone sets the value using a string id, do we immediately look it up and convert it to an object? Do we expect people to set it to an array of string ids? Do we force people to always have full objects?

So at any given time there's such an exponential number of issues I'm dealing with that it makes things difficult to fix. For instance, we COULD just say you're ALWAYS supposed to use <select> and update the ng-options yourself, but now you can't use templating and your values are always string ids instead of rich objects.

It's part of why I believe TwitterBootstrap dropped typeahead and made it it's own component, because they were learning more and more just how complex of an issue this really is.

I think the best solution is to just trash this plugin and rebuild it natively in AngularJS and just support the same DOM and CSS as the original (or bootstrap). But this would mean lots of work to support things like supporting keyboard commands, resizing the input box as needed, and creating those little tag widgets (for multiple select).

If you're interested in that endeavor (and it would be something I could actually HELP with) assuming we design something that can be leveraged by the @angular-ui/bootstrap guys and lots of other people, we could create a new ui-select repo and slowly phase this one out.

Need New Maintainer! #82

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions