Perché debounce e throttle sono importanti nelle UI

Alcuni eventi DOM si verificano a una frequenza estremamente elevata. L'evento keypress si verifica a ogni pressione di un tasto. L'evento scroll si verifica decine di volte al secondo durante lo scorrimento. L'evento resize si verifica continuamente mentre l'utente trascina il bordo della finestra. Elaborare ogni evento singolarmente può sovraccaricare sia il browser sia il server.

Se il gestore di keypress effettua una chiamata API a ogni pressione di un tasto, un utente che digita "React hooks" (11 caratteri) genera 11 richieste di rete, la maggior parte delle quali riguarda query incomplete. Analogamente, aggiornare un'animazione parallasse a ogni pixel di scorrimento provoca centinaia di nuove renderizzazioni di React al secondo. Questo spreca CPU, rete e batteria.

Il debounce ritarda l'esecuzione finché l'evento non smette di verificarsi per un periodo specificato. Se l'utente continua a digitare, il timer viene reimpostato a ogni pressione di un tasto. Solo dopo N millisecondi di silenzio il gestore viene finalmente eseguito una volta. Il debounce risponde alla domanda: "esegui questa operazione quando l'utente ha finito di fare qualcosa".

Il throttle limita l'esecuzione a un massimo di una volta per intervallo di tempo, indipendentemente dal numero di eventi che si verificano. Se l'utente scorre rapidamente, un throttle di 100ms garantisce che il gestore venga eseguito non più di 10 volte al secondo. Il throttle risponde alla domanda: "esegui questa operazione regolarmente, ma non più spesso di ogni N ms".

Il debounce è la scelta giusta quando interessa solo il valore finale, dopo che l'utente ha smesso di interagire. Casi classici: campo di ricerca (inviare una richiesta API dopo una pausa nella digitazione), gestore del ridimensionamento della finestra (ricalcolare il layout al termine del ridimensionamento) e validazione di un campo del modulo che verifica i dati su un server (attendere l'inserimento completo prima della validazione).

Il throttle è la scelta giusta quando si desiderano aggiornamenti regolari durante un'attività continua. Casi classici: gestore della posizione di scorrimento (aggiornare una barra di avanzamento della lettura o un'intestazione fissa a un massimo di 30 fps), monitoraggio del movimento del mouse (registrare la posizione del cursore per l'analisi) e gestori degli eventi di trascinamento (aggiornare senza problemi la posizione di un elemento trascinabile senza generare un numero eccessivo di eventi).

Scrivere un debounce o un throttle da zero senza comprenderne appieno il funzionamento può causare problemi, come la perdita dell'evento finale (trailing edge), l'attivazione sul bordo sbagliato o la mancata pulizia dei timer allo smontaggio del componente. In genere è preferibile utilizzare implementazioni collaudate di librerie come lodash, che gestiscono correttamente tutti i casi limite.

Lodash fornisce _.debounce(fn, wait) e _.throttle(fn, wait), con opzioni per il comportamento sul bordo iniziale e finale. La funzione restituita dispone di un metodo .cancel() per annullare un'invocazione in attesa e di un metodo .flush() per eseguirla immediatamente. In React, queste funzioni devono essere racchiuse in useRef per evitare che vengano ricreate a ogni nuova renderizzazione.

Anche solo 50 renderizzazioni aggiuntive di React al secondo causate da un gestore di scroll senza throttle possono consumare una quantità significativa di CPU, soprattutto sui dispositivi mobili meno potenti. Un budget di 16 ms per fotogramma (60 fps) significa che ogni nuova renderizzazione deve completarsi in meno di 16 millisecondi per evitare la perdita di fotogrammi. Debounce e throttle sono la prima linea di difesa contro i problemi di frequenza dei fotogrammi.

Non tutti i gestori ad alta frequenza richiedono il debounce. Se il gestore dell'evento si limita a leggere un valore senza aggiornare lo stato o chiamare API, ad esempio registrando l'ultima posizione del mouse in un ref, non è necessario usare il debounce. Applichi il debounce o il throttle solo ai gestori che attivano operazioni costose: aggiornamenti dello stato, chiamate API o misurazioni del DOM.

Quando un componente viene smontato, è necessario annullare qualsiasi chiamata con debounce ancora in attesa per evitare un aggiornamento dello stato dopo lo smontaggio. Se utilizza un useRef per memorizzare la funzione con debounce, chiami debouncedFn.cancel() nella pulizia di useEffect. Le funzioni con debounce di Lodash espongono questo metodo proprio a questo scopo.

Quale tecnica dovrebbe utilizzare per effettuare una chiamata API quando l'utente smette di digitare in un campo di ricerca?

Gli eventi ad alta frequenza, come keypress, scroll e resize, possono causare problemi di prestazioni se i gestori vengono eseguiti a ogni evento. Il debounce attende un periodo di silenzio ed è ideale per i campi di ricerca e i gestori del ridimensionamento. Il throttle limita la frequenza ed è ideale per lo scorrimento e il trascinamento. Utilizzi le implementazioni di lodash memorizzate nei ref e le annulli sempre quando il componente viene smontato.