[Filter] deprecate component and expose a filter utility to handle filtering with optional custom filter function

[SkyeSeitz]

monday.com sync: #9562706041

Check existing issues

• I have checked for existing issues to avoid duplicates

Description

Remove the UI of calcite-filter and expose as a utility with a new ability to pass a custom filter function. There is a need to support custom filtering for end-users (see #2208, #2209).

When #10044 and #10186 are closed, deprecate the calcite-filter component.

Acceptance Criteria

UI Considerations

• Add a way to remove the padding (component token?).
• Removing the padding from calcite-filter and add to components that use it (e.g. calcite-list)

Functionality

• Expose filter as a utility that accepts metadata + a value to search
• Allow users to pass a custom filter function to calcite-filter. A few items to consider:
  • custom filter function should support pick/value list filtering
  • could support async methods to allow for complex setups (need to gauge need for this)
  • Enhancement: Provide additional filter options for calcite-value-list #2209 (comment) could be used as a base for the method
  • Consider filtering in components (e.g., list via [List / List items] Support custom filtering supporting a filter function with a prop #6544)

From a designer perspective, it makes the most sense to decouple calcite-filter and its visual UI since it is just an input with padding (which is not always needed). Ideally a developer could choose to use calcite-filter on an input whether or not it is directly adjacent to the filtered UI elements. When built into other Calcite components, I would expect the padding around the input to come from the parent component at the specifications needed, e.g. calcite-list, and not prescribe that padding everywhere calcite-filter is used.

Relevant Info

Blocking Issues: #10044, #10186

Original Filter Function Issue: #3454

Which Component

calcite-filter

Example Use Case

Ease of use for developer implementations and support for typeahead functionality.

Filter doesn't align with other input components in a form

Priority impact

p4 - not time sensitive

Calcite package

• @esri/calcite-components
• @esri/calcite-components-angular
• @esri/calcite-components-react
• @esri/calcite-design-tokens
• @esri/eslint-plugin-calcite-components

Esri team

Calcite (design)

[driskull]

I think we should remove the padding as that makes sense.

I think we still need a UI because we need to wrap and configure the <calcite-input>. It configures input quite a bit so its not something a dev can just easily do.

We should also just expose the filter utility class at some point.

I could see filter being renamed to something like input-filter?

[pllcoster]

I was looking to open a similar issue when I found this one - an additional problem the padding causes is that both the container (with padding) and the filter element use the same variable --calcite-color-foreground-1 for their background color. This means that currently you cannot make the padding transparent but have the filter input background some other color. Removing the padding would also enable easier color customisation.

[driskull]

Would this be considered a visual breaking change?

[SkyeSeitz]

Would this be considered a visual breaking change?

Depends on the route we take..

• Add a way to remove the padding (component token?) - Not breaking
• Removing the padding from calcite-filter and add to components that use it (e.g. calcite-list) - Breaking for anyone using calcite-filter by itself
• Make filter just a utility of sorts that accepts metadata + a value to search - Breaking for anyone using calcite-filter by itself

[github-actions]

Issue #10044 has been closed, this issue is ready for re-evaluation.

cc @geospatialem,@DitwanP