Skip to content

Instantly share code, notes, and snippets.

  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save dfkaye/28847176c8123c76100e23fd437c47d5 to your computer and use it in GitHub Desktop.
Keyboard navigation is a function of the View and *only* the View.

Keyboard navigation is not a state, action, or model activity

OK, an update on my evolving understanding of [SAM done right]. I've added a keydown handler in the calculator app I posted about earlier (scroll up) and it struck me that while keyboard input on a button-driven app can send data to the next Action, keyboard navigation should not do that. Tab and arrow navigation should be handled by the View entirely. Is there a case for sending a next action after keyboard navigation (storing a new focus position, for example)? Any comments are welcome.

(Visit the calculator codepen.)

Answering my own question

Keyboard navigation is a function of the View and only the View.

Yes, you can call action.next() with the current element as the active element if you need to save that for some reason, but I can't think of a good reason to do that.

Implications

In the calculator codepen, the view, rather than the action, is responsible for handling the user or device events (click, tap, press, et al). The result as of 23 May 2020 is that the view internals are getting very heavy while the action API is practically anemic (only action.next which defers to the model).

Keyboard navigation should probably be exported to a separate library that the view imports...

Maybe.

If so, keyboard library method would take regex pattern of keys to match, and a handler function that should define the target type (button, input, form, anchor, details/summary, menu/command), and the desired next step (go back one space, jump to the first value button, etc.).

Modals: the inevitable mixed use case

That means listening to an event to update a region's display state. Dialog, Tab list, Accordion, Error summary to message. Each involes taking over the focus from one region and placing it explicitly on an element inside a modal region. And returning focus when the modal region is dismissed.

Enter, Space on a button to open or close a modal. Escape anywhere in a modal to dismiss it.

Put state transition logic in web workers...

...and leave all the view-dom-event concerns to the view (30 June 2021).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment