4 ms·

If you don't need it to be clever and dynamic, and you're not too bothered about styling, then HTML's <input> tag has a typeahead option using <datalist>. http

If you don't need it to be clever and dynamic, and you're not too bothered about styling, then HTML's <input> tag has a typeahead option using <datalist>. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

bunga-bunga 3y ago
The cool part of datalist is that you can listen to input events on the field, query the server and create your options in the datalist.
- kitd 3y ago
  Yes, I've done this with Htmx. Send the input content to the server and respond with the new <datalist> html that gets automatically swapped in. Really simple engineering.
  - maleldil 3y ago
    Does this mean that every time the user types something, they have to wait a roundtrip from the server for completion? Wouldn't this make this useless for average-to-fast typers? Htmx sounds like a lovely idea, but doesn't it introduce a ton of latency compared to client-side operations?
    - kitd 3y ago
      Well, they "wait" for a fraction of a second maybe. And you put it behind a typing delay so it responds only when the user is ready. Also, many autocompletes do a round trip anyway. The htmx version just returns the html already rendered, rather than, say, JSON that requires further processing and injecting. Here are a couple of Go templates from a sample project that show it: {{define "autoc_data" -}} {{- range . -}} <option>{{.}}</option> {{- end -}} {{- end}} {{define "autoc" -}} <input name="{{.Id}}" id="{{.Id}}" type="text" list="{{.Id}}_data" hx-get="/autoc/{{.Id}}/search" hx-trigger="keyup delay:300ms" hx-target="#{{.Id}}_data"> <datalist id="{{.Id}}_data"> {{- template "autoc_data" -}} </datalist> {{- end}} In response to `/autoc/<id>/search`, the server just responds with a list of strings matching the user's input, formatted with the `autoc_data` template. Htmx injects that into the `<datalist>` directly.
    - zeroonetwothree 3y ago
      That’s how almost all autocompletes work
      - maleldil 3y ago
        Unless you have the data on the client side already, which isn't the case for Htmx.
        MobiusHorizons 3y ago
        In my experience type ahead is most useful on datasets that are generally too large to load the whole dataset locally. There are certainly times when a list is too long to fit in the available space, but unlikely to grow unbounded, but such large lists that are known not to grow in an unbounded manner are rare in my experience.
        kitd 3y ago
        True, but then you are required to load all possible values for all autocompletable input fields at page load, which in many cases is unreasonable. As mentioned, many (most even?) autocompletes do it on the fly, and probably without you realising.
    - solardev 3y ago
      It's how any search engine does autocompletes... you can't possibly store all the queries clientside. Whether you're sending a tiny JSON or a tiny HTML snippet back doesn't really make much of a difference. It's usually fast enough, especially if you debounce/throttle the user input so you're not sending the query on every keystroke.
- Alifatisk 3y ago
  Is there a way to offer an equivalent feature but for people turning off javascript on the web-browser? My first thought is that frameworks like StimulusReflex / Hotwire can do something like that?
  - sublinear 3y ago
    Both of those frameworks require javascript to be enabled for anything requiring an event handler.
jakear 3y ago
At least on Edge, it got continuous substring matching right (illa shows vanilla), but failed to get the most important type of matching: arbitrary substring. Not a surprise, I only know a couple editors that support it. But it's truly the ideal form of filtering, especially when the entries are long. Think css, how much nicer would it be to type "mato" in devtools and get "margin-top"? Or, the ideal case that is somehow still missing – browser history entries: type the first char or two of the hostname, one or two from the path, and a couple form the query, and you've filtered everything down to just one or two options.
- xyzzy_plugh 3y ago
  > Think css, how much nicer would it be to type "mato" in devtools and get "margin-top"? I can't say that this type of search has ever crossed my mind. This type of search would seem to me to be greatly ambiguous. For example, if you have "tomato" in the corpus then that obviously supercedes "margin-top" for the search string "mato". If you know the entire corpus, then I suppose you can take advantage of shortcuts like this when you know there is only one match, but then again it would seem to me that simply writing "margin-top" would require less mental gymnastics.
  - jakear 3y ago
    If you've ever used any filtering in VS Code, this is the algorithm. Re tomato/margin-top, weight is given to matching the prefix exactly, so margin-top does indeed rank higher. https://github.com/microsoft/vscode/blob/main/src/vs/base/common/filters.ts#L350 https://github.com/microsoft/vscode/blob/main/src/vs/base/co...
airblade 3y ago
"Not too bothered about styling" is quite important. Datalists are relatively uncommon and I think many users may not know what they are seeing and how they can interact with it. Also datalists appear quite different across different browsers, which is fine of course for a native form control, but annoying if you're aiming for a more consistent look.
JeremyNT 3y ago
This is a really simple and flexible approach. I just wish that you could natively do something that works more like select elements, so users see the contents of the option elements but the value of the option element is actually what is populated in the form.
- kitd 3y ago
  Isn't that what the `value` attribute of `<option>` is for? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option https://developer.mozilla.org/en-US/docs/Web/HTML/Element/op...
  - PKop 3y ago
    The option and the form will work that way, but the input itself will then show the value instead of the option label... the input is not smart enough to present the option as a select does, it shows whatever you have in the "value" field.
- deleted 3y ago
  [deleted]
psygn89 3y ago
Unfortunately its scrolling performance is kinda laggy around 200 items or so in Chrome. Here's someone's example at 5,000 options which is absurd but you might think it would perform better being that it's a native control. https://jsfiddle.net/klesun/mfgteptf/ https://jsfiddle.net/klesun/mfgteptf/
- xnx 3y ago
  I couldn't detect any lag in Firefox or Chrome on a laptop. Is this more of a problem on older mobile devices?
simlan 3y ago
FYI it does not work on Firefox on Android :(.

bunga-bunga 3y ago

The cool part of datalist is that you can listen to input events on the field, query the server and create your options in the datalist.

kitd 3y ago
Yes, I've done this with Htmx. Send the input content to the server and respond with the new <datalist> html that gets automatically swapped in. Really simple engineering.
- maleldil 3y ago
  Does this mean that every time the user types something, they have to wait a roundtrip from the server for completion? Wouldn't this make this useless for average-to-fast typers? Htmx sounds like a lovely idea, but doesn't it introduce a ton of latency compared to client-side operations?
  - kitd 3y ago
    Well, they "wait" for a fraction of a second maybe. And you put it behind a typing delay so it responds only when the user is ready. Also, many autocompletes do a round trip anyway. The htmx version just returns the html already rendered, rather than, say, JSON that requires further processing and injecting. Here are a couple of Go templates from a sample project that show it: {{define "autoc_data" -}} {{- range . -}} <option>{{.}}</option> {{- end -}} {{- end}} {{define "autoc" -}} <input name="{{.Id}}" id="{{.Id}}" type="text" list="{{.Id}}_data" hx-get="/autoc/{{.Id}}/search" hx-trigger="keyup delay:300ms" hx-target="#{{.Id}}_data"> <datalist id="{{.Id}}_data"> {{- template "autoc_data" -}} </datalist> {{- end}} In response to `/autoc/<id>/search`, the server just responds with a list of strings matching the user's input, formatted with the `autoc_data` template. Htmx injects that into the `<datalist>` directly.
  - zeroonetwothree 3y ago
    That’s how almost all autocompletes work
    - maleldil 3y ago
      Unless you have the data on the client side already, which isn't the case for Htmx.
      - MobiusHorizons 3y ago
        In my experience type ahead is most useful on datasets that are generally too large to load the whole dataset locally. There are certainly times when a list is too long to fit in the available space, but unlikely to grow unbounded, but such large lists that are known not to grow in an unbounded manner are rare in my experience.
      - kitd 3y ago
        True, but then you are required to load all possible values for all autocompletable input fields at page load, which in many cases is unreasonable. As mentioned, many (most even?) autocompletes do it on the fly, and probably without you realising.
  - solardev 3y ago
    It's how any search engine does autocompletes... you can't possibly store all the queries clientside. Whether you're sending a tiny JSON or a tiny HTML snippet back doesn't really make much of a difference. It's usually fast enough, especially if you debounce/throttle the user input so you're not sending the query on every keystroke.
Alifatisk 3y ago
Is there a way to offer an equivalent feature but for people turning off javascript on the web-browser? My first thought is that frameworks like StimulusReflex / Hotwire can do something like that?
- sublinear 3y ago
  Both of those frameworks require javascript to be enabled for anything requiring an event handler.

jakear 3y ago

At least on Edge, it got continuous substring matching right (illa shows vanilla), but failed to get the most important type of matching: arbitrary substring. Not a surprise, I only know a couple editors that support it. But it's truly the ideal form of filtering, especially when the entries are long. Think css, how much nicer would it be to type "mato" in devtools and get "margin-top"? Or, the ideal case that is somehow still missing – browser history entries: type the first char or two of the hostname, one or two from the path, and a couple form the query, and you've filtered everything down to just one or two options.

xyzzy_plugh 3y ago
> Think css, how much nicer would it be to type "mato" in devtools and get "margin-top"? I can't say that this type of search has ever crossed my mind. This type of search would seem to me to be greatly ambiguous. For example, if you have "tomato" in the corpus then that obviously supercedes "margin-top" for the search string "mato". If you know the entire corpus, then I suppose you can take advantage of shortcuts like this when you know there is only one match, but then again it would seem to me that simply writing "margin-top" would require less mental gymnastics.
- jakear 3y ago
  If you've ever used any filtering in VS Code, this is the algorithm. Re tomato/margin-top, weight is given to matching the prefix exactly, so margin-top does indeed rank higher. https://github.com/microsoft/vscode/blob/main/src/vs/base/common/filters.ts#L350 https://github.com/microsoft/vscode/blob/main/src/vs/base/co...

airblade 3y ago

"Not too bothered about styling" is quite important. Datalists are relatively uncommon and I think many users may not know what they are seeing and how they can interact with it. Also datalists appear quite different across different browsers, which is fine of course for a native form control, but annoying if you're aiming for a more consistent look.

JeremyNT 3y ago

This is a really simple and flexible approach. I just wish that you could natively do something that works more like select elements, so users see the contents of the option elements but the value of the option element is actually what is populated in the form.

kitd 3y ago
Isn't that what the `value` attribute of `<option>` is for? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option https://developer.mozilla.org/en-US/docs/Web/HTML/Element/op...
- PKop 3y ago
  The option and the form will work that way, but the input itself will then show the value instead of the option label... the input is not smart enough to present the option as a select does, it shows whatever you have in the "value" field.
deleted 3y ago
[deleted]

psygn89 3y ago

Unfortunately its scrolling performance is kinda laggy around 200 items or so in Chrome. Here's someone's example at 5,000 options which is absurd but you might think it would perform better being that it's a native control. https://jsfiddle.net/klesun/mfgteptf/ https://jsfiddle.net/klesun/mfgteptf/

xnx 3y ago
I couldn't detect any lag in Firefox or Chrome on a laptop. Is this more of a problem on older mobile devices?

simlan 3y ago

FYI it does not work on Firefox on Android :(.