Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

subscription for keyboard up/down arrow #37

Open
ericgj opened this issue Sep 28, 2016 · 3 comments
Open

subscription for keyboard up/down arrow #37

ericgj opened this issue Sep 28, 2016 · 3 comments

Comments

@ericgj
Copy link

ericgj commented Sep 28, 2016

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
Copy link
Owner

gregziegan commented Sep 29, 2016

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

@amitaibu
Copy link

amitaibu commented Nov 1, 2016

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 👍

@gregziegan gregziegan mentioned this issue Nov 19, 2016
@bowbahdoe
Copy link

bowbahdoe commented Feb 16, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants