Applicazioni pratiche: ricerca, scorrimento, ridimensionamento

In un componente di ricerca in tempo reale, mantenga due variabili di stato separate: inputValue per l'input grezzo, che si aggiorna a ogni pressione di un tasto e mantiene reattivo il campo di input, e debouncedQuery ottenuta da useDebounce(inputValue, 300), che si aggiorna 300 ms dopo che si è smesso di digitare e avvia la chiamata API. Questa separazione fornisce un feedback visivo immediato senza generare richieste eccessive.

Mostri un indicatore di caricamento non appena l'utente inizia a digitare, non soltanto quando inizia la chiamata API. Imposti isLoading: true ogni volta che inputValue !== debouncedQuery: i due valori non sono sincronizzati mentre il debounce è in attesa. Quando la query si è stabilizzata e il recupero dei dati è completato, lo reimposti su false. In questo modo, l'utente vede un indicatore di caricamento reattivo per tutta la durata dell'operazione.

Un effetto parallasse o una barra di avanzamento della lettura si aggiorna in base alla posizione di scorrimento. Limiti la frequenza del gestore dello scorrimento a un massimo di 60 fps utilizzando un ritardo di 16 ms: const throttledScrollY = useThrottle(scrollY, 16). L'interfaccia utente si aggiorna in modo fluido senza il costo di ricalcolare la posizione a ogni pixel dello scorrimento.

L'ascolto del ridimensionamento della finestra per ricalcolare il layout va gestito con debounce, non con throttle. Il calcolo del layout deve essere eseguito una sola volta, dopo che l'utente ha terminato di ridimensionare la finestra. Applichi un debounce di 200 ms alle dimensioni della finestra. Durante il trascinamento per il ridimensionamento, l'interfaccia può mostrare uno stato semplificato; il layout ricalcolato appare quando il ridimensionamento termina.

Quando debouncedQuery cambia, crei un nuovo AbortController e passi il relativo signal a fetch(url, { signal }). Restituisca una funzione di pulizia che chiama controller.abort(). In questo modo, una nuova query sottoposta a debounce annulla qualsiasi richiesta precedente ancora in corso, evitando condizioni di gara in cui una risposta precedente e lenta sovrascrive una risposta successiva e più rapida.

Senza AbortController, se l'utente digita "re", attende e poi digita "react", la seconda query potrebbe restituire i risultati prima della prima, ad esempio a causa della memorizzazione nella cache. I risultati della ricerca mostrerebbero brevemente quelli di React, per poi essere sovrascritti dai risultati obsoleti di "re". AbortController evita questo problema annullando completamente la richiesta precedente.

Il menu a discesa combina il debounce per le chiamate API e lo stato immediato per la visualizzazione dell'input. inputValue controlla ciò che appare nel campo di testo. useDebounce(inputValue, 250) controlla quando viene avviato il recupero dei suggerimenti. L'elenco dei suggerimenti viene visualizzato a partire dallo stato dei risultati recuperati, che è separato da entrambi gli stati dell'input.

La validazione asincrona di un modulo, ad esempio per verificare se un indirizzo email esiste già, dovrebbe utilizzare il debounce per evitare di sovraccaricare il server a ogni pressione di un tasto. Applichi un debounce di 400 ms al valore del campo e avvii la richiesta di validazione in un useEffect che dipende dal valore sottoposto a debounce. Mostri un indicatore di caricamento nel campo mentre la validazione è in attesa.

Il debounce è ideale per salvare automaticamente il contenuto di un modulo mentre l'utente digita. Imposti un debounce di 1000 ms sull'oggetto contenente i valori del modulo. Quando il valore sottoposto a debounce cambia, avvii un salvataggio in localStorage o su un endpoint API. L'utente vede l'indicatore "Salvataggio in corso..." mentre il debounce è in attesa e "Salvato" al completamento della richiesta.

I valori del ritardo sono decisioni relative all'esperienza utente. Per la ricerca, 200-300 ms rappresentano un buon compromesso tra reattività e riduzione delle richieste. Per il ridimensionamento, 150-200 ms sono accettabili perché gli utenti si aspettano che il layout si stabilizzi dopo il ridimensionamento. Per il salvataggio automatico, 1000 ms lascia il tempo di digitare una frase prima del salvataggio. Adatti il valore in base alla velocità di interazione prevista.

Le applicazioni reali spesso richiedono più ottimizzazioni simultaneamente. Un editor di documenti potrebbe applicare il debounce al salvataggio automatico (1 s), il throttle al calcolo del numero di parole (500 ms) e utilizzare IntersectionObserver per l'analisi. Queste tecniche si combinano bene perché ciascuna opera in modo indipendente con il proprio timer e nel proprio ambito.

Perché dovrebbe utilizzare AbortController insieme a una query di ricerca sottoposta a debounce?

Utilizzi useDebounce per gli input di ricerca, i gestori del ridimensionamento e il salvataggio automatico dei moduli. Utilizzi useThrottle per lo scorrimento e il movimento del mouse. Combini sempre le chiamate API sottoposte a debounce con AbortController per evitare condizioni di gara. Mostri lo stato di caricamento ogni volta che inputValue !== debouncedQuery per mantenere l'interfaccia reattiva e informativa.