Autocomplete: select only the filtered items, or expose the filtered collection in a selection callback

[rilescode]

Provide a general summary of the feature here

When an Autocomplete filters a multi-select collection, provide a way to select only the items currently matching the filter, and/or expose the filtered set of keys/nodes in a callback so the consumer can compute that selection itself.

🤔 Expected Behavior?

Either (or both):

1. A "select all" that resolves to the keys currently passing the Autocomplete filter (could be an opt-in selectAllBehavior="filtered" on the wrapped collection inside an Autocomplete) or
2. A callback that surfaces the currently filtered collection (its keys or Nodes), so a "select all filtered" can be implemented in user space.

😯 Current Behavior

Autocomplete exposes only filter?: (textValue, inputValue, node: Node) => boolean and owns no selection API. SelectionManager.selectAll() calls setSelectedKeys('all'), and since Selection = 'all' | Set, onSelectionChange returns the literal 'all'. 'all' is not filter-aware and does not enumerate keys, so there is no way to select or even read the filtered subset

💁 Possible Solution

Add a selectAllBehavior: 'all' | 'filtered' (or similar) honored by a collection rendered inside an Autocomplete, so select-all maps to the filtered keys.

Alternate solution: Expose the filtered nodes/keys from Autocomplete (render prop or callback) so the consumer can derive the selection. Today the only workaround is to fully control filtering (see #8084) and the collection externally, duplicating state.

🔦 Context

We use Autocomplete over collections that support "select all." When a user searches, we want "select all" to just select visible/filtered matches, but we cannot implement this: select-all yields 'all', and we have no handle on the filtered key set (without doing some hacky stuff like reading collection state in child components, which contains the filtered collection. see #9395)

💻 Examples

No response

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[snowystinger]

I think there's a workaround here so long as you're using a dynamic collection (not static).

You have the filter function, so you could run your data through it to see if it matches. Then, if you ever see onSelectionChange give you 'all', you can just check for everything that matches the current filter (by running it through the filter) and set the selected keys to that list.

This way you don't need to read the collection state in child components.

[rilescode]

I think there's a workaround here so long as you're using a dynamic collection (not static).

You have the filter function, so you could run your data through it to see if it matches. Then, if you ever see onSelectionChange give you 'all', you can just check for everything that matches the current filter (by running it through the filter) and set the selected keys to that list.

This way you don't need to read the collection state in child components.

@snowystinger Appreciate the response. This works but it means I have to keep my own copy of the current input value and re-run the same filter over my full data on every select all, just to reproduce the set the component already filtered to render. So the filtering happens twice and I have to mirror the input state.

[rilescode]

@snowystinger If I were to take a stab at this in a contribution, would you lean toward a new selectAllBehavior or exposing the filtered keys in an callback / render prop on autocomplete?

[snowystinger]

Yep, I was just aiming to get you unstuck.

I think some quick history about 'all' might be useful in this. The goal of 'all', rather than returning a set of all the currently loaded items, was to make it possible for users to have 'all' also mean everything that hasn't been loaded async either. Unfortunately, filtering can also have async results, which means you'd need to be aware of the filter and apply it to anything on the server as well potentially if you're performing an action, and any new items coming in that make it through the filter should automatically be selected.

I think, given that goal, we're going to need to discuss this as a team. Adobe has a shutdown coming up, so API discussions will probably be slow for a few weeks. If you'd like to consider it on your own and submit something akin to an RFC or a prototype, that would definitely help the discussion. The most important piece of information being, what is the driving, real world, use case. Any descriptions or screenshots of this component as it would appear in an application would be very helpful.