Allow calcite-list to search without the search box

[fangqidev]

Check existing issues

• I have checked for existing issues to avoid duplicates

Description

We want to use a single search box for multiple calcite-list-based widgets at the same time in the ExB (For example, layerlist, tablelist, and basemaplayerlist). Right now, the calcite list is only able to filter items with a search box (by setting visibleItems.filter to true in the JS API).

Acceptance Criteria

An option to hide the search input box when filter is true and the items number exceeds minFilterItems. So we can use a single self-implemented search input box for several calcite lists at the same time. For example, we can apply the same search content for a layerlist, a tablelist, and a basemaplist.

Relevant Info

JSAPI issue: https://devtopia.esri.com/WebGIS/arcgis-js-api/issues/64561
ExB issue: https://devtopia.esri.com/Beijing-R-D-Center/ExperienceBuilder-Web-Extensions/issues/21467#issuecomment-4979724

Which Component

calcite list

Example Use Case

No response

Priority impact

impact - p2 - want for an upcoming milestone

Calcite package

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

Esri team

ArcGIS Experience Builder

[thming]

cc @geospatialem

[geospatialem]

Added design for expertise on the UI/UX and if Calcite should consider for list.

[thming]

Some more information:
The lack of this feature has blocked the implementation of ENH-000167930, so we decided to withdraw this feature to the next release and wait for this capability to be added, otherwise, the behavior in the ExB Map Layers widget would look like a bug to users. It would be great if it could be supported in the next one. Thanks!

[macandcheese]

Not sure there are design implications here - to a user, there should be no difference between if an app has filtered the displayed List Items with their own logic or if they filter with the built-in List filtering.

With that - is the ask here just to allow filter-text to take effect and perform filtering without filter-enabled?
I think that makes sense to support ... cc @geospatialem @driskull

[driskull]

With that - is the ask here just to allow filter-text to take effect and perform filtering without filter-enabled?
I think that makes sense to support

The issue with this is that filtering is handled at the filter component level which has a UI. We would need to move the filtering logic to the list instead. cc @jcfranco

[macandcheese]

Ah right, maybe once this and related issues land this could be easier to tackle. #10187

[fangqidev]

Hi @macandcheese , I'm wondering if this issue is planned for the next release on the calcite side. The ExB team is planning a new feature that depends on this issue in 25R1.

[macandcheese]

Cc @geospatialem for timing, but it doesn’t seem to be in an upcoming milestone.

As a workaround, is it possible to filter the List Items shown in each display without using the List’s built in filter - just filter with your own logic based on the value of the single search input?

This would, to a user, be the same, if I’m understanding the initial ask.

[thming]

@macandcheese @geospatialem
The initial request is to support tables and the basemap layers inside the Layer List, so we have to put the TableList and Basemap widgets inside the LayerList widget. The current behavior is like - see that the key cannot take effect to filter out the target inside the table list:

To make the search universal, we need the search key taking effect outside of the search box, so we can implement our own search and pass the typed-in key to all three widgets. Writing our own logic can cause some maintenance issues later so we are suggested not to do that.

This request is a parity of Web AppBuilder. The remaining tasks were asked to be added to portal 11.5, which pulls the code from 25R1. So, for us, this would be the release that it needs to be in.

[driskull]

I think this needs a Maps SDK issue as well if it needs to be something supported within the LayerList/BasemapLayerList/TableList widgets.

[geospatialem]

This request is a parity of Web AppBuilder. The remaining tasks were asked to be added to portal 11.5, which pulls the code from 25R1. So, for us, this would be the release that it needs to be in.

@thming This will not be part of 25.R1 due to other initiatives for Calcite's 3.0 release that have been planned for the last 3 Online releases. At this time the enhancement request is not targeted for an upcoming milestone in 2025, but will be triaged to an upcoming milestone in the future once the team is able to triage it after other enhancement requests.

Currently Calcite team members prioritize regressions and bugs, however the team continues to adapt new components and feature enhancements in alignment with the design system. That said new component and enhancement requests may take multiple releases before implementation. If other teams are also seeking the enhancement request Calcite team members may prioritize it over older enhancement requests.

[geospatialem]

The above has been mitigated by #6544 with the new filterPredicate boolean and verified in 3.0.0-next.79 with https://codepen.io/geospatialem/pen/MYgprGg

The example showcases custom filtering with a standalone input that supplies the value through list's new filterPredicate boolean prop. Filtering displays in this case for the list-item's label and description, but could be further modified as-needed.