possible feature: autocomplete input field

[rokadias]

So I've seen issue #87 but I think the typeahead autocomplete there is overkill. I'm really looking for an easier way for users to type into a text box and search through a known set of values (using fuzzy search of course).

Basically what you can find here in the react material ui library:
http://www.material-ui.com/#/components/auto-complete

[Thanood]

Do you think the search field from the Materialize website would fit your description?

I just recently saw that it has autocomplete. I mean really, I've looked at the site at least a thousand times since I began this project but only recently I typed something into that text box. 😄

We could probably use that as a base.

[Thanood]

Autocomplete is now implemented in the current materialize release 0.97.7. http://materializecss.com/forms.html#autocomplete

I'll add it to the bridge as soon as I can.

[Thanood]

Personally, I find their implementaton is lacking. For example:

• no keyboard navigation for suggestions (key up/down)
• no destroy/refresh function (again) - made it destroy itself, though
• pressing enter inserts the first suggestion hit

But well, here we go. 😄
Will release that change on Wednesday. I'd like to see if I can squeeze some more changes in.

[rokadias]

Yeah, I would like the key up/down, but aside from that this looks like what I was looking for.

Thanks.

[droda59]

Personnally I don't understand their autocomplete control. You have to have the whole data before you do anything, which in most cases is useless, except if you're entering a state.
It would be great to have an autocomplete which could have a callback binding that returns data, and that data would be converted to the format used by materialize (which is an object, instead of an array).

[Thanood]

I did add a refresh method with that in mind (also triggered when values change). Refresh is what you get when you click "set other values" in the example.

You could technically load data from the server and (convert data and) assign autocomplete values at that time.

I'd like to stay as close as possible to Materialize implementations (in general) because who knows what future features they will implement. These will have to be integrated here and there are already a bunch of improvement proposals in their repo (because, honestly, there is a lot of room for autocomplete improvements).

Having said that, I'm all for improving usage simplicity and your auto-width idea IMO shows that you like that, too. 😃
So if you have an idea how to improve this, you're of course invited to contribute.

Edit:
This gist would show (simulate) how to fetch values from a server if i had updated the gist bundle (shame on me):
https://gist.run/?id=4e6abfdd6c3c8bc5cfdb0dfd5f74780b

I need to update that. 😃

[droda59]

Oh you're right, I didn't realize refresh() deleted the <ul> and re-created it with the values.
Staying close to the official Materialize library is the right way to go!

[droda59]

Altough I realize there may be a bug now, if you try to attach it to a regular input.
if (this.element.tagName.toLowerCase() === 'input') this.input = this.element;
This sets this.input and this.element as the actual <input> element.
But then when you try to fire the change event or detach the autocomplete-content, you use the input as the context for the jQuery selector.
$('.autocomplete-content', this.element).remove();
But since the input doesn't contain the autocomplete-content, nothing happens.

[Thanood]

Maybe I've overlooked something but here is what I thought:
this.input should be either the element itself or a child of the element. So $('.autocomplete-content', this.element) should also return children of this.input. Is this not the case?

[droda59]

Not if applied on an actual <input> element, since it cannot have children.

[Thanood]

Oh, of course! 😄
Thanks for pointing that out.