[Feature Request]: Programmatically control selectedItems in Filterable MultiSelect

[ask-42]

Summary

The non-filterable MultiSelect was enhanced to allow you to pass selectedItems to fully control it (#10236).

It would be nice if the Filterable MultiSelect allowed this as well, as we need this functionality. I currently work around this issue with a hacky solution involving subclassing the component, but I'd prefer not to do that, and it won't be an option anymore once it has been migrated to being a functional component. Right now it only supports initialSelectedItems, but I need full control over the selection even after mounting.

Justification

No response

Desired UX and success metrics

No response

Required functionality

selectedItems can be programmatically controlled.

Specific timeline issues / requests

Before or alongside any release that migrates the component to be functional instead of class-based.

Available extra resources

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[abbeyhrt]

We would love to have this contributed! We think it's a great feature to have and similar to MultiSelect, we would love to help out anyone who would want to contribute this solution!

[mthaak]

The extra confusing thing is that since the FilterableMultiSelectProps TypeScript type extends MultiSelectProps in @types/carbon-components-react (see here), the selectedItems prop is present on the FilterableMultiSelect and so you don't get any errors if you provide it. But actually the selectedItems argument is being ignored

This deficiency is preventing me from updating the selected items programmatically after the component has been mounted

[mthaak]

This is a fix:

<MultiSelect.Filterable
    ...
    initialSelectedItems={mySelectedItems}
    // A random key enforces the remounting of the component every time the parent is rendered
    key={Math.random()}
/>

But it's not obvious and requires the FilterableMultiSelect to be remounted every time

[sstrubberg]

Per @tw15egan's comments during Backlog Cleaning this morning. We would need look at mutliselect and see if we can port the changes made in #4812 to filterable multi-select. Possible design guidance based on this. It could be a healthy amount of sprint work, if mutli-select is portable. But if not, it could take much longer.

[marconuccetelli]

@mthaak's solution works for updating data, but it causes the list to scroll up whenever something changes within the component. Any news on this functionality?

[sstrubberg]

Unfortunately, no movement has been made by the maintainer team on this request. Due to roadmap constraints, we've identified this as work we would love to see the community take up by creating a PR. We'll let you know if anything changes!

[ychavoya]

Hi, I'd like to be assigned this issue is possible to work on it, thanks!

[tw15egan]

@ychavoya would #16139 also resolve this issue?

[ychavoya]

@tw15egan No, the Filterable MultiSelect does not have any implementation on controlled input. I actually ran into the issue that that PR solves by trying to explore this feature

[tw15egan]

Ah, my mistake, @ychavoya; I did not see the distinction that this issue is regarding FilterableMultiselect

[ychavoya]

Hi, just FYI I noticed that the changes from #16147 may add this functionality since it seems to implement the useSelection hook used in the regular Multiselect. It may be worth to check when that PR is done