Multi select and autocomplete on AngularJS

With multiple choice lists on Angulyar has always been unimportant. Existing solutions or wrappers over jQuery-plugin , or look like you do not understand that , or just clumsy . And everyone naturally has a special unique API, as if users have nothing more to do than to delve into the train of thought of the developers of each plug-in. I was not satisfied with this state of affairs, so I wrote my bicycle. A year later, he matured before publication.

Ta-dam! (and a funny story in the end)

tamtakoe.imtqy.com/oi.select


First of all I decided: no own API, no third-party libraries, and no design of my own. The select should be as close as possible to the standard only with the possibility of autocompletion and creation of new options in it. API should also be compatible with Angular select, which in turn is compatible with HTML select. The standard appearance could not be used, since it is determined by the browser, so it took the most common Bootstrap as the basis. In fact, it was not a new component, but an extension of the existing one.
')

It is necessary to appreciate the time of their colleagues, not to force them to study the new format of parameters in order to do what they have long been able to do; reckon with the skills of users who expect a component of a habitual appearance and behavior. The first thing that a developer should do when designing interface elements is to kill a designer in himself. Not in the plan, to make the design somehow, but to make the most of the existing behavior, to add from myself as a last resort, but to change at the very last.

API turned out to be fully compatible, with the exception of setting options via <option> . In HTML, this method is used because there is no other. In Angulyar there are controllers and models, there this method was left for compatibility. I was too lazy to do this compatibility. Maybe one day…

At the very beginning, there were three ways to create such a component: implementation on pure JS with DOM manipulations and so on, extension of the Angulyarovsky select directive, implementation mainly on Angulyar. Since I'm not smart enough to make such decisions in my head, I just took and implemented all three ways:

1. The most tempting thing is to write your select by analogy with Angulyarovsky. Pure JS, maximum performance, everything under control. But it was not easy to do this: there are too many nuances, knowledge of Angulyar at the lowest level is required, a lot of copy-paste functions that Angulyar implements inside. As a result, all this falls out in many thousands of lines of code with all the consequences. I refused this idea, although it would be suitable for simple components.
   
2. You can use Angular's select directive in your directive. Extend it, redefine methods, etc. It sounds good, but in fact it turns out too crutch. Still, Angulyar does not yet allow for the expansion of its components, especially directives (unfortunately), therefore expanding with JS means you are tied to internal implementation and you risk losing backward compatibility. This method is acceptable in directives where the extension is provided by developers, for example, Angular-bootstrap popover .
   
3. The implementation of Angulyar tools turned out to be simpler and clearer. From copy-paste only Regexp for parsing parameters from ng-options . The code is simpler than on pure JS and does not require knowledge of the internal structure of the Angulyarovsky select. Productivity is good (for which I was most afraid). I think this method is suitable for the implementation of most components.
   

Despite the compatibility with the API, there are enough unique parameters. I suppose there is still not all smooth and obvious, so I will be glad of comments in the comments. A lot of things related to the creation of new items from the input line. After some analysis, I came to the conclusion that there are two cases of using the input field with prompts:

• prompt - the field works like a normal input, and the list just displays hints. By pressing Enter, the value from the field is entered into the model. The field can be cleared and then there will be an empty string in the model. This behavior is typical for the search form.
  
• autocomplete - the field works as a list with options. By pressing Enter, the first option from the list gets into the model and only if there was nothing there - the contents of the input field. You cannot write an empty string to the model. This behavior is typical for the tag entry form.
  

Another controversial item: custom design options. In the standard component (even angulyarovskom, even bootstrap) nothing like this. But everyone wants. I came to a compromise solution - to make support for filters for everything and everyone. Of course, you have to write HTML in JS, but the speed is higher and much easier than bothering with template support (and what could be the templates for the list item?). However, someday ...

And now the promised funny story for mastered the page of the text without pictures.

In one version there was a bug that none of the developers of the web department could reproduce. But the rest of the staff: managers, analysts, testers, 1C-programmers reproduced in any case. It got to tears - behind one computer some people always choose an element from the list, others do it no matter how hard they try. I think this property can be used when hiring people to work. Bad programmers will not pass the test. Check yourself and you, the reader .