Then, you could have a workflow “on change” on the select so that the collection is fetched with the search value when the user starts typing. Make sure to include a short delay in the workflow to streamline the API calls when the user is typing.
I tried this, but the issue is that in the tags mode, the value of the select is only set when a selection is made (aka the tag is added). The value of the select is not updated as the user is typing.
Ah, my bad! I thought I’d made it work that way in a prior project but maybe not. I might have been playing around with the “Search with results” element instead. Have you tried that?
It requires a bit of work to style the options as you’d like but it can be very powerful and has the debounce in-built. One drawback compared to the select element: it won’t close if the user clicks outside the search results.
It’s a little bit annoying because the select elements have some pros and cons and the searches too. The product team is currently working on a way to standardize these elements so that you have all the pros and no longer have to explore different options to see which one might fit best with a few tweaks.
Yes, I use the Search with results element already in my app. And will tweak it to my needs as you suggested, unless weweb’s team revamp the multiselect in a reasonable time frame? Any insight on this?
“…it won’t close if the user clicks outside the search results”: I guess I can tweak that behavior too.