WeboracleArtikkelen forklarer hvorfor debounced søk bør designes sammen med API-et. Den tar for seg forsinkelse, AbortController, minimumslengde, cache, statuskoder, tomme resultater og belastning på server.
Debounced søk blir ofte behandlet som en liten JavaScript-detalj. I praksis er det et samspill mellom brukergrensesnitt, API, database og serverbelastning.
Minimumslengde og tomt søk
API-et bør vite hvordan det håndterer korte søk. Ett tegn, tomt søk og brede søk må ha bevisst oppførsel, ellers blir både brukeropplevelse og serverbelastning uforutsigbar.
Avbryt gamle forespørsler
Hvis brukeren skriver raskt, kan eldre forespørsler svare etter nyere. AbortController kan brukes til å avbryte forespørsler som ikke lenger er relevante.
API-et bør returnere nok kontekst
Et søkesvar bør inneholde søketermen det gjelder, antall treff og en tydelig liste. Da kan frontend kontrollere at svaret fortsatt hører til det brukeren faktisk har skrevet.
Rate limiting og cache
Søk kan bli tungt hvis mange brukere skriver raskt. API-et bør ha fornuftige grenser, og vanlige søk kan eventuelt caches. HTTP-status 429 kan brukes når klienten sender for mange forespørsler.
WEBoracle-vurdering
WEBoracle bør bruke samme mønster for søk i scripts, artikler og tutorials: minimumslengde, debounce, avbrutte forespørsler, tydelig JSON-svar og tilgjengelige statusmeldinger.
Konklusjon
Debounced søk er ikke bare en timer i frontend. Det er et produktmønster som må støttes av API-et. Når begge sider er designet sammen, får brukeren raskere søk og serveren mindre unødvendig arbeid.