subscription for keyboard up/down arrow
ericgj opened this issue · 3 comments
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.
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: 299ae09
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
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 👍
Is there an update on when this will happen? Is it safe to depend on this for a project or will this library disappear?