Is a search request necessary when triggering clear()

[searls]

I just wired up hw-combobox#clear for the first time (on a page with up to 20 comboboxes) and was a little surprised that clearing them out triggered the async search separately for all of them:

@josefarias is this intentional/necessary, you think?

[josefarias]

Good callout @searls!

The short answer is this is intentional.

Pardon the crude example from the gem's dummy app. I've added a "Choose your movie!" async combobox to the external-clear test. Here's how it works with the filtering on:
https://github.com/user-attachments/assets/14be3f1d-2717-43ae-9fd9-626cefbf5860

Here's how it works with the filtering off, notice you don't get a full list of options after clearing:
https://github.com/user-attachments/assets/69dca8d0-18d7-4709-baba-f9a5f10e08b7

The X also doesn't change back to a chevron but that's an implementation detail that's easily fixable.

On to the long answer... This happens because of how the infinite pagination is implemented. In the current system, it's the action of filtering that requests a lazy cascade of turbo-frames from the backend, where each frame knows what the query is. This makes for simple, maintainable code, for both the library and the end-user. But it does require we filter after clearing — so the turbo frame knows what the right query is the next time the listbox is revealed.

I can see how seeing a burst of 20 requests is surprising. But in the end Turbo is designed to be a server-backed solution. I think ideally the server should be able to handle the load. But I'm open to hearing cases for why it shouldn't if it's causing active problems.