[EuiSelectable] Evaluate supporting groups and "bulk" selection
Problem Statement
Working with groups of options in EuiSelectable is not ideal.
There are "group labels" (with the option.isGroupLabel setting):
An option is allowed to be passed that is just a header for the options that follow it. It takes no mouse handlers and renders similar to a title.
but since there's no parent-child relationship in the component state, searching can break hierarchies and provide useless results (if you search for "foo" and there was a group under the "foo" heading, you'll see the heading but not its options).
It would also be useful to be able to do bulk selection (checking or unchecking all options in a group).
Request by @ArtemS-ela @jovana-andjelkovic
Proposed Solution
Make the component handle groups in a smarter way, in order to:
- enable better searching for groups
- allow bulk/group selection
Value / Impact
🟡 TBD
Do alternatives or workarounds exist?
Kind of. Searching could be improved with some custom logic in a custom optionMatcher function. And bulk selection is possible lifting the options state and adding controls to the group labels via append/prepend, but these appear to have accessibility issues.
- workaround implementation in Kibana
- https://codesandbox.io/p/sandbox/objective-gauss-5mxxkh
Additional context (Optional)
This came as a request in Slack.
Designs or Specs (Optional)
Sketch ideas from consumer:
New option shape:
groupId?: stringfor children.isGroup?: truefor group rows (instead of isGroupLabel).
New props on EuiSelectable:
allowGroupSelection?: boolean(default false).groupSelectionScope?: 'all' | 'visible'(default 'all').onGroupToggle?(groupId: string, next: 'none' | 'all', scope: 'all' | 'visible'): void(optional hook; if omitted, component manages state internally like it does for single items).renderGroupControls?(state: 'none' | 'some' | 'all', groupId: string): ReactNode(custom action area).selectGroupOnLabelClick?: boolean(wrap group label in a <label htmlFor>).
@acstll Can you please add the person whom requested this to the description? That helps us determine who communicate updates to.
While we don't want to link to Slack conversations in an issue, using the Slack feature to generate a summary of the conversation, including a date the conversation happened, and mentioned who requested it in that Slack conversation helps as well.
Thank you for adding this issue. We've triaged it to determine priority and next steps:
- New status: Backlog
- Priority: We are not prioritizing this work.
- Next steps: We are unlikely to complete this work, but we’d happily review a pull request if you’d like to contribute a PR.
If you believe this should be prioritized differently, please feel free to add more context here (e.g., how it impacts your work, or how broadly it might affect other users). That helps us re-evaluate priorities.