[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 #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 https://github.com/Esri/calcite-design-system/issues/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.

[nwhittaker]

Thank @ashetland -- looks really good!

One clarifying question on the single-selection mode. When a child is selected and the parent is clicked to collapse and then clicked again to expand, we'd need the child to remains selected. Is that doable?

Other than that, I think the single-selection mode will work well for us, @ade10176?

[ashetland]

Yep, that is the intent for both single and multiple. I've added a clarifying note to the Figma file that can be seen here:

[ade10176]

Agreed w/ @nwhittaker looks great @ashetland !

[ashetland]

Thanks all!

[ade10176]

Looking to get this supported in Calcite so we can use it in Field Maps @ashetland

[driskull]

I'm not really sure I understand this issue. It would help if the requests were separated into separate issues for filtering and selecting. Could we do that?

With regards to the selection requests, I think this is why we have different selection modes.

[driskull]

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

This one seems odd to me.

Parent list-item is not visible when no descendent leaf items match.

This should be Parent list-item is not visible when no descendent leaf items match and parent does not match correct?

I think this is how these are already working. Is there a repro where we can see the unexpected scenario?

[nwhittaker]

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

This one seems odd to me.

The Example Use Case section should flesh out the reasoning for this behavior. To clarify, our parent list items are group layers which have no actions or selection behaviors (other than open/close) associated with them. As a result, it doesn't make sense for Field Maps to show them in the results if they don't contain any matching leaf layers.

In other words we're interested in finding non-group layers within a nested, or non-nested, layer structure. Groups should fail the filter if it makes them appear to be empty.

---

Parent list-item is not visible when no descendent leaf items match.

This should be Parent list-item is not visible when no descendent leaf items match and parent does not match correct?

Your edit makes sense in the context of the previous requirement. However, as a standalone requirement, it's more complete to say if none of the descendants match, we want to hide the parent regardless if it itself matches.

---

It's not narrowly scoped to the requirements of this issue, but I have an old codepen prototype that tests out the list functionality in the context of how we'd be using it. It might be helpful to check out to get a feel for what we're looking to do.

Depending on how specialized our requests are getting, there's certainly flexibility on our end in terms of how declarative the API is. For example, adding support for the hidden attribute to <calcite-list-item> so we can hide it ourselves, if needed.

[driskull]

For example, adding support for the hidden attribute to so we can hide it ourselves, if needed.

The hidden attribute should already work on list-item's as well as any other component.

I think we could support custom filtering through a property where a user can define their own filter logic by supplying a function. That seems like it would be best to handle all these use cases.

[nwhittaker]

The hidden attribute should already work on list-item's as well as any other component.

I did not find that to be the case: https://codepen.io/nwhittaker-esri/pen/MWxaLRp. I'd expect all the list items to be hidden there.

I think we could support custom filtering through a property where a user can define their own filter logic by supplying a function. That seems like it would be best to handle all these use cases.

Yes, I think this approach would work well for us.

[driskull]

Ah, yeah the filter is removing it. Can you open a separate issue for this? We can fix it by hiding filtered items differently so we are not using the hidden attribute.

[driskull]

@geospatialem can we repurpose this issue to instead "support custom filtering logic"? Allowing a user to provide a filter function via a property.