[EuiTable] [EuiSearchBar] Filter improvements

[thomheymann]

Follow up to #6900

1. Ability to group filters

There are a lot of management screens in Kibana that group related filters together for better visual clarity.

In order to achieve this teams currently have to build their own bespoke search bar using EuiFilterButtonGroup and EuiFilterButton primitives. It also requires them to create their own bespoke filtering logic that EuiTable would otherwise include out of the box.

It would be great if EuiTable and EuiSearchBar would have the ability to add a separator (empty space) to separate different filter groups.

We could use a similar mechanism to EuiContextMenu which renders a separator when you pass in an item as { isSeparator: true }.

2. Ability to set numFilters

When using filters provided by EuiTable or EuiSearchBar the numFilters property is not correctly populated.

The only way to set this property currently is to create a filter as a custom component using EuiFilterButton primitive which requires implementing bespoke filtering logic that is, field_value_selection, field_value_toggle and field_value_toggle_group filter types would include out of the box.

It would be great if it would be possible to either manually set this or to infer it based on the filters provided since it improves usability by surfacing the number of filters available without users having to open the popover.

It would also help avoid inconsistencies in how different teams interpret this property with some teams incorrectly using the numFilters property to denote the number of active filters (See screenshot above) when it’s supposed to denote the total number of filters available.

3. Make onChange a required prop or clarify use case

When creating a custom component filter the component render function prop has its onChange prop marked as optional. I'm not sure if this is intentional but I don't understand when the change handler would be undefined and how the filter should behave in such a case. It's not possible to apply any filter without the onChange handler so there would be no point in rendering the filter in the first place:

const filters: SearchFilterConfig[] = [{
    type: 'custom_component',
    component: ({ query, onChange }) => (
      onChange ? <CustomFilterFilterButton query={query} onChange={onChange} /> : '??????'
    ),
}];

<EuiSearchBar filters={filters} />

[tkajtoch]

@thomheymann Thank you for your detailed improvement requests! We'll look into each of them, see how complicated the changes would be and we'll put them on our regular development schedule or support schedule depending on complexity. In any case, I'll keep you posted.

Is there a specific timeline you're expecting these improvements to be delivered in?

[thomheymann]

@thomheymann Thank you for your detailed improvement requests! We'll look into each of them, see how complicated the changes would be and we'll put them on our regular development schedule or support schedule depending on complexity. In any case, I'll keep you posted.

Is there a specific timeline you're expecting these improvements to be delivered in?

Thanks Tomasz, that makes sense to me.

The highest priority enhancement for me would be "1. Ability to group filters", since I can't currently implement the design without going fully bespoke and replicating lot of logic from EuiSearchBar.

The feature I am working is required for 8.10 but since this is a visual enhancement it should not be a blocker.

[github-actions[bot]]

👋 Hi there - this issue hasn't had any activity in 6 months. If the EUI team has not explicitly expressed that this is something on our roadmap, it's unlikely that we'll pick this issue up. We would sincerely appreciate a PR/community contribution if this is something that matters to you! If not, and there is no further activity on this issue for another 6 months (i.e. it's stale for over a year), the issue will be auto-closed.

[github-actions[bot]]

❌ Per our previous message, this issue is auto-closing after having been open and inactive for a year. If you strongly feel this is still a high-priority issue, or are interested in contributing, please leave a comment or open a new issue linking to this one for context.