[List / List items] Support custom filtering supporting a filter function with a prop

[nwhittaker]

Description

A way to opt in to an stripped-down behavior when clicking a list-item that contains nested list-items.

Originally included selection and filtering asks, now placed in two separate issues:

• Filtering (below)
• Selection via [List item] Child elements behavior can be toggled open without selection change and event dispatch #8515

Acceptance Criteria

Filtering a list of items with nested list-items:

• Parent list-item is visible when it does not match but any leaf items do match.
• Parent list-item is not visible when it does match but no descendent leaf items match.
• Parent list-item is not visible when no descendent leaf items match.
• Consider [calcite-filter] Add support for custom filter function #3454 as part of the upcoming effort

Relevant Info

No response

Which Component

calcite-list-item

Example Use Case

The Field Maps web app would like to use the calcite-list element to display the layers in a map. For group layers, nested layers are shown as child list-items.

Selecting a leaf layer navigates the app for further handling of the layer. However, the app does not provide further handling for group layers. They are treated more like folders that organize sets of layers -- so clicking them in the list should have no effect other than to drill down to leaf layers.

Esri team

ArcGIS Field Apps

[brittneytewks]

Scheduling time with FieldApps to understand use case in more depth, will add priority and estimate after discussion

[nwhittaker]

Added some stripped-down filtering behavior to the issue description that should also be part of any discussion.

[geospatialem]

Reallocating to the May release for design considerations.

[ashetland]

Propose we model the changes to List selection behaviors after what is outlined in issue #6912 for Tree. This likely means adding a children selection mode and modifying the behaviors of single. I've started mocking this up today.

[ashetland]

Selection modes

Final proposal for revising the existing single and multiple selection-modes and adding children and multichildren can be found in this Figma file. See also the image below. This would be consistent with changes to Tree in issue #6912 and pr #6926.

Filtering

Since the parent would still be selectable in children and multichildren, I propose the current filtering behavior be retained for these modes.

For the revised single and multiple, however, the behaviors outlined in the original post should be adopted:

Filtering a list of items with nested list-items:

Parent list-item is visible when it does not match but any leaf items do match.
Parent list-item is not visible when it does match but no descendent leaf items match.
Parent list-item is not visible when no descendent leaf items match.

Nested indentation levels

With these new/revised selection modes, nested indentation behavior should be reconsidered as part of issue #6632.

@nwhittaker, let me know if we've missed anything here.

[geospatialem]

@geospatialem @DitwanP what would you expect this custom filter prop on the list to be named?

Naming is hard 😅 - was trying to think of a way we could add filter... to the beginning part of the prop name for consistency with other filter props, but came up empty. @driskull Dig the direction you headed with customFilter. 🥇

[nwhittaker]

@geospatialem @DitwanP what would you expect this custom filter prop on the list to be named?

Naming is hard 😅 - was trying to think of a way we could add filter... to the beginning part of the prop name for consistency with other filter props, but came up empty. @driskull Dig the direction you headed with customFilter. 🥇

A predicate function is one that always returns true or false. How about filterPredicate?

[driskull]

@geospatialem @DitwanP Should the custom filter function require that filterText be defined? (not empty string) or should we allow the custom filter function to worry about the filterText property? I lean towards not having a requirement that it be set. It could allow users do their own filtering independent of the UI.

The other question is should filterPredicate work even when filterEnabled is false?

[driskull]

Actually, I think i like the filterPredicate, ill go with that.

[geospatialem]

Should the custom filter function require that filterText be defined? (not empty string) or should we allow the custom filter function to worry about the filterText property? I lean towards not having a requirement that it be set. It could allow users do their own filtering independent of the UI.

Also lean towards not having a defined filterText be a requirement, otherwise it might make the story a bit confusing for devs to implement.

The other question is should filterPredicate work even when filterEnabled is false?

Maybe we should lean towards supporting it regardless of filterEnabled? If so, could this potentially accommodate #10258?

[driskull]

Maybe we should lean towards supporting it regardless of filterEnabled? If so, could this potentially accommodate #10258?

Agreed.

In the future, we should still allow filterText to work without the filter UI. This would require decoupling filtering from the ui.

[github-actions]

Installed and assigned for verification.

[geospatialem]

Verified with 3.0.0-next.76 and https://codepen.io/geospatialem/pen/vEBxZqy

const listEl = document.getElementById("custom-list");

listEl.filterPredicate = (item) => {
  if (listEl.filterText === "test") {
    return true;
  }

  return item.value === "item2";
};