fix: FASTSelect not opening/closing when multiple attribute is set
DavidVollmers opened this issue · 8 comments
🐛 Bug Report
In the latest version 3.0.0-alpha.31 the FASTSelect component is not opening or closing when clicking it. You can only open and close it using the enter key. This is due to the variable collapsible which returns false when multiple is true. My guess is that this is intended to not close the select when selecting values (since it's a multi-select), but unfortunately the current implementation doesn't open/close on click if collapsible is false:
https://github.com/microsoft/fast/blob/master/packages/web-components/fast-foundation/src/select/select.ts#L322
🤔 Expected Behavior
The FASTSelect component should still open/close on click when multiple is set to true.
🌍 Your Environment
- Version
3.0.0-alpha.31
I played around with this by forcing collapsible to always return true. But then there are further problems when it comes to using the multiple selection select. My guess is that this was never truly implemented to this day?
I played around with this by forcing
collapsibleto always returntrue. But then there are further problems when it comes to using the multiple selection select. My guess is that this was never truly implemented to this day?
Multiple should be supported, but this more closely mirrors a native select behavior where the listbox stays persistent. There would be work to do to enable collapsible multi-select as well as the native behavior. I think there may be a feature request out there somewhere for this; if not, that's a good place to start. Curious if @bheston, @radium-v, @KingOfTac, or @scomea have thoughts on having this contributed.
I think the question here is how closely Foundation wants to match the platform and where it makes sense to deviate from that to match what other component libraries are doing.
With that being said I think this is a reasonable feature to add. Perhaps we could decouple the selection mode from the collapse/persistent states of the select menu and add a persistent Boolean attribute that matches the native select's behavior for multi select, but that's just one of many possible solutions.
A select in multi-selection mode can't collapse by design. The two major usability challenges are 1) communicating to a user that a collapsible multi-select allows multiple options to be selected; and 2) displaying the currently selected options while the multi-select is collapsed.
IMO the Picker component would probably make more sense for this sort of functionality.
Agreed on use of Picker instead. I've been planning to write up a few additions I'd like to see added to Picker, but from a design system perspective I find it has replaced many scenarios where Select and Combobox may have previously been used.
While I understand the argumentation about using the picker component I have to admit I dislike the implication of it. I believe the FAST framework should be as flexible as possible, so that it allows to only deliver one single component for both scenarios. It feels wrong to me to force all FAST built design systems to adopt the same philosophy.
I don't object to select having a "picker lite" multi-select behavior as long as it conforms to accessibility specs and solves some ux issues like what multi-selection looks like in the input when the menu is closed.
Note that picker enables a bunch of scenarios that aren't typical of "select" components and has extensive support for custom templating, operates on objects as data rather than strings, loading options based on input query changes, etc...