refactor: add useSetFocus controller

[jcfranco]

Related Issue: N/A

Summary

This adds a controller for consistent and simpler setFocus behavior across components.

Noteworthy changes

• updates dom#focusElement() to use focusFirstTabbable(el) instead of calling el.focus() if there's no setFocus() available and adds context argument to allow short-circuiting focus logic
• adds includeContainer to dom#focusFirstTabbable, dom#getFirstTabbable for focus target scope
• updates dom#focusElementInGroup() to support includeContainer and whether to consider the target element as the focus context
• adds internal dom#focusFirstFocusable, dom#getFirstFocusable for additional focus options – can expose if deemed useful
• automatically skips focusing if the component is disabled
  • converts interactive.spec.ts test to interactive.browser.spec.tsx to support ☝️
• setFocus controller supports customization for advanced use cases, such as
  • defining focus strategy – use first-tabbable (default) vs first-focusable (both from tabbable)
  • setting target scope – excludes container (default) or not when looking for first tabbable/focusable
• complex focusing cases will still work, but will be external to the controller (e.g., list's focusCell calls).
• for granular or custom, internal focusing, use focusElement instead of this.setFocus, unless that behavior is desired

Next steps

• refactor utils to use object parameters for clarity as they are getting complex
• refactor external focus logic to use setFocus controller, if possible

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity. Please close your PR if it is no longer relevant. Thank you for your contributions.

[jcfranco]

Went with focusSetter as the default name for the internal prop holding the controller export, but open to suggestions.

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity. Please close your PR if it is no longer relevant. Thank you for your contributions.

[aPreciado88]

This LGTM!

[driskull]

This is nice! awesome ⭐

[eriklharper]

Went with focusSetter as the default name for the internal prop holding the controller export, but open to suggestions.

Yeah, I've been thinking it would be good to standardize the naming structure for the internal component properties meant for storing controller instances. I feel like the word "controller" in the name, however verbose, could be nice because it is direct? I think maybe the name of the controller, plus the word "controller" could be the most direct way we could adopt, so it would be come useSetFocusController.

[jcfranco]

Went with focusSetter as the default name for the internal prop holding the controller export, but open to suggestions.

Yeah, I've been thinking it would be good to standardize the naming structure for the internal component properties meant for storing controller instances. I feel like the word "controller" in the name, however verbose, could be nice because it is direct? I think maybe the name of the controller, plus the word "controller" could be the most direct way we could adopt, so it would be come useSetFocusController.

Not sure this is applicable since a controller’s return value can be anything, including nothing.

[eriklharper]

Went with focusSetter as the default name for the internal prop holding the controller export, but open to suggestions.

Yeah, I've been thinking it would be good to standardize the naming structure for the internal component properties meant for storing controller instances. I feel like the word "controller" in the name, however verbose, could be nice because it is direct? I think maybe the name of the controller, plus the word "controller" could be the most direct way we could adopt, so it would be come useSetFocusController.

Not sure this is applicable since a controller’s return value can be anything, including nothing.

True. I also think the usage of controllers across the code base is easily discoverable by searching for the controller imports, so it probably doesn't matter whether we establish naming guidelines for the instances. I do like the name focusSetter because it is communicating the action it is intended to produce.