Custom debounce interval?

[hockleyd]

Looking through the code, it appears the debounce on async events (I'm not that well-versed in the front end, so apologies in advance if this is pre-beginner thinking) is set to 150 ms. Without altering the library code itself, is there a way to change this value, or otherwise to manage that aspect of the interaction?

[josefarias]

Hey @hockleyd, there's no way to manage that value right now. What's the use case for changing it?

[hockleyd]

Perhaps I'm forcing the use of the component into realms it is not intended, but I've got it actually using a geocoding service through the back end. Typing an address is a bit more laborious than the 150 ms, and looking for the more "standard" 400ms (or 500ms for the big round number) of debounce delay to slow down the number of queries to a DB for this more intensive search.

Then, ideally, I'm looking for the select event when something is chosen without relying on a form submit to process that address and update the page via turbo streams, but that's a separate discussion around the close event and other potential events I've read in other threads.

[josefarias]

Hmm no, I think this is a legit use case. I'm fairly sure you could monkey-patch your way there. But we might want to support this natively.

One other question – If I understand correctly this is a case where you want to give your server more breathing room to avoid hammering it with intensive requests, correct? Or is it a case where the UX is worsened by a quicker response time? Or both?

If it's the former, I'm not sure that an increased debounce time will help a whole lot because the problem will just come back as you get more users using the system simultaneously. It points to query optimization being the thing to address, I believe.

[hockleyd]

Bit of both, as some partial matches are just a waste of bandwidth and delay. e.g. the user knows a chunk of the address and types it easily, but gets a pile of results flickering up that are not useful as they matched on the smaller fragments quickly. As for the server breathing room, that is fortunately a horizontal scaling situation that can be solved proportional to the user load. There's also caching patterns possible as user behaviour gets more "worn-in" for these use cases, but that's specific to this app.

[josefarias]

#259