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.)
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.
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.).
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.
...and leave all the view-dom-event concerns to the view (30 June 2021).