Non-blocking searching
under review
Evan Boyle
When searching with few filters, it lags a few seconds before loading results. This is normal, but when searching for something by typing from scratch, like ECON 159, it searches E (which takes a few seconds), then EC (which takes a few seconds), and so on before you finalize your search. This could be alleviated by having searches be non-blocking and then just discard the results if a new search query is placed.
R
Reyansh Bahl
marked this post as
under review
R
Reyansh Bahl
I’m not sure how often people hit this in practice (vs. paste or type quickly), but this is plausible.
For a bit of context on what we're already doing, search isn’t issuing a network call per keystroke. We load the catalog once, then the results are updated from client-side filter + sort. that work is also debounced (300ms) with both leading and trailing invocations, so in the common case rapid typing is meant to batch into fewer passes rather than one per letter.
if we can reproduce multi-second stalls with a concrete scenario (device + season + filter setup), we're happy to treat it as a real UX issue. if not, we might leave it unless we see more signal. thanks for the report!