feat: add retainFocus config parameter

[rambah]

What kind of change does this PR introduce?

• Bugfix
• Feature
• Documentation
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes
• No

Other information:
This PR introduces a new configuration parameter, preventDefaultTabKeyWhenListOpen, which controls the behavior of the Tab key when the list of suggestions is open.

New Feature: preventDefaultTabKeyWhenListOpen
This feature allows users to customize how the Tab key behaves when the suggestions list is open.

• Default Behavior:

  • When the suggestions list is open, pressing the Tab key will select the first suggestion and keep the focus in the input field. To move the focus to the next element, the user must press the Tab key again.

• New Configuration Option:

  • The preventDefaultTabKeyWhenListOpen config option is introduced to modify this behavior. When set to false, pressing the Tab key will select the first suggestion and immediately move the focus to the next element on the page.

By default, this option is set to true, preserving the existing behavior.

See video for explanation:

preventDefaultTabKeyWhenListOpen set to true (default):

Here you can see, that you have to press twice the 'Tab' key to move the focus to the next element.

Screen.Recording.2024-06-26.at.15.15.26.mov

preventDefaultTabKeyWhenListOpen set to false:

Here you only have to press once the 'Tab' key to move the focus to the next element of the page.

Screen.Recording.2024-06-26.at.15.14.48.mov

[niketpathak]

Hello @rambah , I understand what you are trying to achieve here, but this is not a good practice and is also not good in terms of UX.
When the list is open, a single tab should first close the list and select the closest option (notifying the user that an option was selected automatically)
Instead, if the tab key jumps to the next available input field, then we might have to clear the search field because perhaps the user didn't want to even select anything and yet we did without giving a chance to the user to know that the option was selected.

[rambah]

Hi @niketpathak, thank you for your feedback. I understand your concern regarding user experience. However, the motivation behind this change, comes from a specific use case where rapid form filling is critical. In workflows where speed and efficiency are essential, like for trained professionals, users often prefer to trust their input and minimize the number of keystrokes needed to fill out a form.

(Imagine a form with about 7 typeahead input fields... the number of tab keystrokes is reduced from 14 to 7)

The proposed change does not aim to replace the current behavior but rather provide an option for those who need it. By setting the config param to false, we allow environments that prioritize speed & efficiency than UX. For general use cases, the default setting remains true, ensuring UX is prioritized.

[niketpathak]

hmmm. I see your point @rambah. I also agree the number of keystrokes is doubled albeit its the same key. Nonetheless, let me ponder on that for a bit to see if I can come up with something more elegant. will get back to you when able. Thanks again for your input/contribution.

[rambah]

@niketpathak We can also work together on that issue. Just tell me if you got an idea on how to improve that solution :)

[rambah]

@niketpathak We could change the name from preventDefaultTabKeyWhenListOpen to for example:

• retainFocus, where the default is set to true
• preserveInputFocus, where the default is set to true

[niketpathak]

Hello @rambah , thank you for taking the time for this and sorry about the delay. I cannot think of a better solution than proposed by you. Although the name retainFocus is much more convenient. So i think we can go ahead with that instead.

[rambah]

Hi @niketpathak, alright, thanks. I will change it accordingly and update PR. :)

[rambah]

@niketpathak Updated.