Hacker News Reader

Comment by SoftTalker | Hacker News Reader

> I added an AbortController to the debounced search function, so that it aborts any previous queries when a new one is made. This means that the search results are always relevant to what the user is currently typing.

To me one of the most annoying things an application can do is go off and do something before I'm done telling it what to do. Filters that apply themselves without an explicit indication that I'm done setting them up, or searches that are constantly re-executing as I'm typing. Wait for me to stop.

View on HN

When I implemented search-as-you-type on my blog, I decided to wait for the current search suggestion request to complete before doing a new one. Seemed like a reasonable balance between responsiveness and not overloading the server.

When I implemented one I simply filtered the results that came back from previous requests to see if they matched what the user had typed in the mean time. That way the UI might get relevant results with lower latency than would otherwise be possible with no risk that a non-matching result would show up to confuse the user.

The video showing the problem in the article seems to show an avalanche of queries towards the server, I'm surprised no one cared about it, but I guess it's frontend people thinking "It's the backend/ops that have to deal with the problem!".

I wait about 250 ms before firing the request, if the user (well, me) continues typing, then the timer gets cancelled and the app waits another 250ms.

Firing queries all the time is especially annoying if your users are in another continent, and you don't have proper state management to only show results for the latest query, as opposed to the latest response.

RTT from Europe to AWS us-* can easily get to multiple seconds during peak times.

The earlier search will be on a shorter input which will find more results; imagine waiting for everything that contains "e" before you can get the one result for "europa" that you wanted. Isn't that pattern going to happen most of the time - waiting for a large amount of useless generated and transferred and disposed-of, before the search you want will run?

That's why I set it to run after the third letter and only return up to 7 suggestions. In your example, it wouldn't run until "eur", which should narrow it down quite a bit. Given my rather small blog article corpus and aggressive full text search indexing, it's very fast.

I hate this on booking websites. Especially if the filters are in a sidebar on the left and do not fit your viewport and every god damn time you change something it scrolls up, starts loading, puts filters into read only mode until it's done just so you can add the next filter...

Grafana log search does this if change the currently-applied log filter, and then they charge you for search volume!

I've had to adjust my UX usage so that I don't get billed for every character I type, rather than the string I'm looking for.

I think a good middle ground is to wait a few hundred ms at least, for the user to stop typing, before sending off the query. Or maybe, still send the query, but don't populate results until they stop.

It is loathable and contemptible behavior. I despise it. Writing in fancy code editors is an exercise in "remember this display was very expensive calm down".

> type out 'i' and 'f'

RED ALERT! RED ALERT! UHHHHH HEY THERE CHAMP YOUR IF-THEN STATEMENT ISN'T CLOSED OUT PROPERLY!

Yeah, I know, I'm not done fucking typing yet. Give me a second.

Thankfully I can usually turn this crap to only show these after a certain delay, for many languages I write in I usually turn it off completely except for on build/run. Let the complier/shell throw me errors, the LSP can take a chill pill.

Datadog if you see this

Reply on news.ycombinator.com