useDebouncedCallback evita ricerche con stato obsoleto in React

Digitare “react”, attendere 300 ms, ricevere risultati per una ricerca vuota: l’articolo su dev.to spiega perché accade e propone un hook chiamato useDebouncedCallback per evitarlo¹.

Il problema nasce da una closure stantia in un componente che debounca la ricerca. L’esempio mostra un SearchBox con due state locali, query e results. Ogni pressione di tasto aggiorna query e pianifica una richiesta. Prima di impostare il nuovo timer, la funzione cancella il precedente. Il codice costruisce l’URL con fetch(/api/search?q=${query}) e attende 300 ms prima di eseguire la chiamata¹.

La funzione che pianifica la ricerca, scheduleSearch, è creata con useMemo. Dentro, una variabile locale timer tiene l’identificatore del timeout. L’URL è costruito a partire da query catturata quando la funzione memoizzata è stata creata. Quello era il primo render, in cui query valeva stringa vuota. Si digita “react”, si aspetta 300 ms, e si ottengono i risultati di una ricerca vuota¹.

Il risultato si vede subito. L’input è vivo. I dati sono congelati. La closure è stantia, perché legge il valore di query del primo render invece di quello aggiornato dall’ultimo onChange. L’interfaccia riflette i tasti premuti, il codice interroga la rete con una query obsoleta¹.

La gestione del timer segue uno schema noto di debounce. Il codice cancella il timeout precedente con window.clearTimeout(timer) e ne imposta uno nuovo con window.setTimeout, sempre a 300 ms. In scheduleSearch vive la variabile locale timer che conserva l’identificatore del timeout tra le chiamate della funzione memoizzata. Questo organizza l’attesa tra una digitazione e la successiva, ma non risolve il problema della closure che usa query catturata al primo render¹.

Qui entra in scena useDebouncedCallback. L’hook, spiega l’autore, ferma un callback ritardato quando rischia di eseguire con uno stato obsoleto. Inoltre mantiene stabile l’identità del timer anche quando il callback cambia a ogni render. In altre parole, il timer resta stabile mentre il callback può aggiornarsi a ogni render, così l’effetto di debounce non perde coerenza temporale e non si porta dietro uno stato “di ieri”¹.

Il punto del post non è “debounce sì o no”, ma come evitare che la closure congeli lo stato. Nell’esempio, la funzione che pianifica la ricerca è memoizzata e cattura query al primo render. Quel valore entra nella costruzione dell’URL e resta quello, anche dopo altri render. Il comportamento osservato è lineare rispetto a questa scelta: l’input si aggiorna a ogni battuta, ma la richiesta inviata dopo 300 ms usa ancora q=""¹.

L’articolo condensa il problema in una riga: “L’input è vivo. I dati sono congelati”. Da qui la proposta: usare un hook che impedisca al callback ritardato di leggere uno stato obsoleto e che mantenga stabile l’identità del timer anche quando il callback cambia a ogni render. La combinazione mitiga la closure stantia mostrata nell’esempio e consente di allineare la chiamata di rete all’ultimo valore di query disponibile¹.