[filter] Add a property that doesn't match filter inputs

[sagewall]

Check existing issues

• I have checked for existing issues to avoid duplicates

Description

Adding a new unique identifier property possibly named uid to the list-item component. This new property doesn't get matched when filtering the list. This would allow for assigning unique id's to list items and not have to worry about unexpected results appearing in the list after filtering.

Acceptance Criteria

A new property that doesn't get matched for filtering.

Relevant Info

We are currently appending unique identifiers into the value property but they are being matched by the filter leading to unexpected list items remaining in the list after filtering.

Which Component

list-item

Example Use Case

Adding unique identifiers to layers, tables and bookmarks in the ArcGIS Maps SDK for JavaScript LayerList, BasemapLayerList, TableList and Bookmarks widgets.

Priority impact

p3 - want for 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 Maps SDK for JavaScript

[driskull]

This would actually be for the filter component.

The filter component has an items property where you can specify the list of items to be filtered as an object.

The issue is that everything within that object is used to filter data. So you can't really add a unique identifier to that object that isn't filtered. Because the filter just spits out the same object its difficult to identity and map the object to its original item.

We would propose a new API which allows for adding a unique identifier to that object that is not counted as filter data.

[sagewall]

@geospatialem is there any way to get this implemented for the JS SDK's 4.31 fall release?

[jcfranco]

We would propose a new API which allows for adding a unique identifier to that object that is not counted as filter data.

Would #5063 help achieve this?

[driskull]

Yeah I think that would suffice.

[jcfranco]

Awesome, thanks for confirming. Closing in favor of #5063.