gregziegan/elm-autocomplete

A simple example of old-style behavior or higher-level component?

maximsch2 opened this issue · 7 comments

maximsch2 commented

It seems like new API is vastly more powerful compared to the old one at the expense of being vastly more complicated. I've attempted a migration to it, but now I'm stepping back and re-evaluating to see if it makes sense to do it. For context, I have a bunch of different auto-complete fields in different portions of the web app and manually handling input/query/showMenu stuff is getting reaally boring.

Do you think it makes sense to wrap this around into higher-level component that would embed input and menu and provide functionality similar to the one in the first autocomplete field on the new demo page?

maximsch2 commented

Something like this (based of AccessibleExample.elm): https://gist.github.com/maximsch2/1dcdb170fd5f2cdb7a3a1b1499cdc62d

gregziegan commented

@maximsch2 yes, I actually made this milestone once i released v4 to revisit this and think about how to make drop-in more possible.

https://github.com/thebritican/elm-autocomplete/milestone/3

  • 👍1
gregziegan commented

Right now, I'd just suggest copy/pasting the AccessibleExample.elm and then customizing it. Nest it in your app. But I want to revisit it very soon! I will read up on your gist soon.

maximsch2 commented

Sounds good! My gist is actually just an AccessibleExample.elm made a bit more reusable, so might be a good starting point for an embeddable component

ericgj commented

I took a crack at a generic-ish version of the AccessibleExample for my needs --
https://gist.github.com/ericgj/a383febb4703715fef44752e29ca3ad3

  • Items must be List (id, item)
  • selectedItem is Maybe id, not Maybe (id, item) .
  • The items are not included in the model but in a Config record that gets passed in to both view and update. In keeping with your second rule of thumb: "Never put any config in your model".

In the common case where your lists of items are loaded separately from the model that has these items as autocomplete selections, where you are likely pulling in the lists of items from further up the state tree from where the model is constructed, it seems to me a lot more flexible to have the list in config. But this seems to cause problems with subscriptions, which I'm putting in a separate issue.

See what you think.

isaacsanders commented

#47 Might be relevant to this discussion

justgage commented

Yeah this is hurting adoption for me personally.