Replies: 4 comments 9 replies
-
|
Leaning a bit on @reach/combobox, what do you think about separating props declared on the component itself, from props inherited by native HTML elements? Props declared on the
Props inherited from
|
Beta Was this translation helpful? Give feedback.
-
|
Thoughts on the component behavior for keyboard navigation:
Thoughts on maintaining component state:
|
Beta Was this translation helpful? Give feedback.
-
|
And just a few suggestions for general requirements:
|
Beta Was this translation helpful? Give feedback.
-
|
@benja I think you have done a great job with the flow chart and mapping out the different states of the combobox. I find the complexity a bit intimidating, and the number of different requirements and design choices is taxing and time-consuming to work through. In order to keep the momentum up, should we perhaps try to simplify some things? I would at least try to adopt as many things as possible from a similar component in another framework, or to keep the scope as small as possible. Just my two cents, since I also feel responsible for this RFC and would hate to become a bottleneck and an obstacle for changes that may be useful for more people. |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Problem
The Combobox is a complex component with lots of functionality. To build one that fits our needs we have look at a wide variety of use-cases and attempt to find a solution that solves a multitude of problems, whether it is internally in the component or through component customisability.
During the lifespan of the current component, we've realised that the use-cases vary quite a bit from team to team, making it a bigger challenge to create the "perfect" component. However, it is not impossible, it just requires an open discussion so we can make compromises if needed and agree on a solution.
Where are we now?
The current version of the Comobox is entirely custom built with no external dependencies. We have tried to imitate Reach's component in functionality to the best of our ability, but there are a few quirks here and there. It might currently function a bit different to what we would expect to use in FINN products.
Where are we heading?
In updating the current version of the component, we are trying to follow the ARIA spec more closely: https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html (Example 3) & https://www.w3.org/TR/wai-aria-practices-1.2/examples/combobox/combobox-autocomplete-list.html. Please do let us know if you have any immediate thoughts, comments or further sources on this.
Properties
There have been discussions back and forth regarding properties and when/how to pass certain events. How we do this is entirely up to us, as long as we remain consistent in how we choose to do it.
E.g. fire
onSelectwith the option value if the user has navigated to one of the options without pressingEnteror clicking itonBlurwith either the input value, or the navigation option value if the user has navigated to an option...etc
See some of the improvements we have already made here.
It would be nice to have an open discussion around how you would expect the component to behave. How are you currently using the component within your team and what problems have you stumbled upon using the current version? If you have any questions, concerns or feedback, do feel free to leave them below!
Beta Was this translation helpful? Give feedback.
All reactions