Autocomplete view

1

I’ve been working on an Ember-based autocomplete view for a project I am working on, available in this gist. I posted a comment on Twitter for feedback to the approach/design etc to get some feedback. @trek graciously responded and we had a brief debate about UI libraries etc. I received no real guidance from anyone and I am still seeking such.

I want to make an important note that I am not trying to make a UI library etc, just a widget for a particular purpose. My intention is to not start this debate.

I’ve attempted this multiple times with multiple rewrites and I still end up at the same place. I assume that means I’m not wrong but I want to be sure and gauge others on their opinion.

Another note, the reason the majority of the code is in the view is because it belongs in the view. It’s all view state stuff etc. Of course I could break this out into templates and other views but until I need to re-use anything it’s just a waste of effort for this use case.

2 Likes
2

Just too be curious: Why don’t you build upon an autocomplete library like jquery-ui’s autocomplete library? Is there a reason for that? I implemented 2 autocomplete views for our app too and i was happy with the library.

3

Several reasons. The first being I want to deal with Ember Objects which I can’t see how it’ll work well with a 3rd party library. Secondly, because I don’t want to add extra dependencies that are not required. If I was using more of jQuery UI other than the autocomplete functionality then I might consider it. It’s also more difficult to customise the appearance of the results with other libraries without hacking.

The most important reason though is this is an exercise for me at learning Ember and things are best constructed. Just like Rails, Ember is opinionated and has a certain way of doing things. I want to get familiar with those things and this situation puts me in the thick of it. Being a new library though means there’s little (up-to-date) examples and knowledge on such things. This will change in time of course, just helping to kick start it.

4

From my experience creating some widgets for ember, yours is in good shape. Using ContainerView and breaking it down to pieces is the way to go. Make it easier to reuse classes.

Sill, you could create a Dropdown view class in isolation. To use outside the autocomplete class and just instantiate it in your dropdownView. That way you would be forced to think in how to design the two classes in a more decoupled way.

Maybe you could take a look in one of my widgets for ideas. Maybe this one: https://github.com/guilhermeaiolfi/emberjs-ui/blob/master/packages/emberjs-ui/ColorPickerView.js . I had to create a SpinnerView , a SliderView and one or more mixins to make it easier.

As you’ll see, this code is pretty old (last changed was made 10 months ago). So, don’t expect it to be flawless or anything close to that.

5

I know that you already started your own implementation, but just in case you would like to try integrating some other widgets, you don’t necessarily need to use widgets directly in the code. I was using YUI widgets in one of my apps (it was the time when Ember.js was not yet renamed from Sproutcore2.0) and it could look like:

App.AutocompleteView = Ember.View.extend({
  resultHighlighter: 'phraseMatch',

  didInsertElement: function() {
    this._super.apply(this, arguments);
    var input = Y.one( $()[0] );
    input.plug(Y.Plugin.AutoComplete, {
      resultHighlighter: this.get('resultHighlighter'),
      resultTextLocator: this.resultTextLocator.bind(this),
      source: this.get('source'),
      // etc...
    });

    input.ac.on('select', this.onSelect.bind(this))

    this.set('input', input);
  },

  onSelect: function(e, result) {
    // logic for selected item
  }
});

As you see, you may just wrap a widget with Ember.View and call view’s methods on events which you need to handle. Now when you inherit from such View, you will just use Ember code.