search

gregziegan / elm-autocomplete

Autocomplete for Elm apps; in Elm
http://package.elm-lang.org/packages/thebritican/elm-autocomplete/latest
BSD 3-Clause "New" or "Revised" License
173 stars 43 forks source link

subscription for keyboard up/down arrow #37

Open ericgj opened 8 years ago

ericgj commented 8 years ago

Just wanted to confirm, in order to get menu navigation behavior with the keyboard, you have to Sub.map the autocomplete subscription, all the way up your app tree, correct? Essentially menu navigation is done through a global keyboard handler -- which is why in the examples you do NoOp + stopPropagation = false for up/down arrow keydowns in the input element?

If so, I'm having a bit of a dilemma. On the one hand, I would prefer to have my list of items not be part of the model state, but be passed in separately as config/context/props, for reasons mentioned in #36 . But this bit of context (a little detail like the list of items!) wouldn't be available when the Keyboard subscription bubbles up, so there's no way to update the menu based on these keyboard events.

Maybe there is no other way but including the list in the model, but that is extremely inconvenient from the point of view of how typical state trees are constructed :( at least in my understanding.

gregziegan commented 8 years ago

Hi! I'll be visiting and thinking through this and your other comment on #36 very soon 😸

There was a commit (before squashing + merging) where I was considering providing an input element for this scenario. It's in this description: https://github.com/thebritican/elm-autocomplete/commit/299ae09f6a6cde865dbab84996580db4af50685d

If I expose input, we can place a custom decoder to handle keyboard movement rather than subscriptions.

I'll look more closely at your Gist soon too!

My current idea is to move this repo and API to something like elm-menu. So you can use this API to completely customize your menu and its mouse/keyboard events while correctly storing position (key, mouse) for you.

Then, this repo becomes a drop-in WAI-ARIA widget. I expose much less customization. It will behave like the AccessibleExample and a sectioned one will behave the same (so i'll need to do a little work).

Basically: using elm-autocomplete will become very little work for the common case. But you can always use elm-menu for more complicated needs

Complicated needs like: Textarea mentions Contenteditable mentions And more where navigable menus are useful

amitaibu commented 8 years ago

Basically: using elm-autocomplete will become very little work for the common case

That would be great. I'm to show an example of how to connect elm-autocomplete with elm-simple form, and currently the elm-autocomplete is taking a lot of code. Having to deal only with simpler wiring, and serving the common case would be 👍

bowbahdoe commented 6 years ago

Is there an update on when this will happen? Is it safe to depend on this for a project or will this library disappear?