Concetti fondamentali di SWR: stale-while-revalidate

SWR è l'acronimo di Stale-While-Revalidate, una strategia di caching HTTP definita nella RFC 5861. La strategia consiste nel fornire immediatamente all'utente i dati obsoleti (memorizzati nella cache), quindi nel rieseguire la validazione in background e nell'aggiornare l'interfaccia quando arrivano dati aggiornati.

Questo approccio privilegia le prestazioni percepite: gli utenti visualizzano subito i dati invece di attendere un andata e ritorno sulla rete.

Con i modelli di caricamento tradizionali, gli utenti vedono un indicatore di caricamento a ogni navigazione. Con SWR, visualizzano immediatamente gli ultimi dati noti e l'interfaccia si aggiorna silenziosamente in background se i dati sono cambiati.

In questo modo le applicazioni sembrano notevolmente più veloci e si riduce l'interruzione cognitiva causata dagli stati di caricamento.

SWR riesegue automaticamente la validazione dei dati quando: la finestra del browser torna in primo piano (l'utente cambia scheda e poi ritorna), la connessione di rete viene ripristinata dopo essere passati alla modalità offline, viene chiamato esplicitamente mutate(), oppure scatta un timer refreshInterval configurabile.

Questi trigger automatici mantengono aggiornati i dati senza che lo sviluppatore debba gestire manualmente la logica di refetch.

Una chiave SWR può trovarsi in uno di diversi stati: loading (nessun dato nella cache, prima richiesta in corso), revalidating (dati presenti nella cache, aggiornamento in background in corso), error (richiesta non riuscita) oppure success (dati aggiornati disponibili).

Comprendere questi stati La aiuta a creare skeleton di caricamento accurati e interfacce per gli errori.

SWR mantiene una cache globale in memoria indicizzata dalla chiave della richiesta (in genere una stringa URL). Qualsiasi componente che richieda la stessa chiave riceve lo stesso valore memorizzato nella cache e partecipa allo stesso ciclo di revalidazione.

Questa deduplicazione automatica consente a 10 componenti di chiamare ciascuno useSWR con la stessa chiave, effettuando una sola richiesta di rete.

SWR separa la logica di gestione della cache dal recupero effettivo dei dati. Si fornisce una funzione fetcher: una funzione asincrona che accetta la chiave e restituisce i dati.

Il fetcher è sostituibile: può utilizzare fetch, axios, graphql-request o qualsiasi altra origine dati asincrona. SWR gestisce la memorizzazione nella cache e la revalidazione indipendentemente dal funzionamento del fetcher.

Avvolga l'app in SWRConfig con una prop value contenente una funzione fetcher: value={{ fetcher: (url) => fetch(url).then(r => r.json()) }}. Ogni chiamata a useSWR che omette un argomento fetcher utilizza questo valore predefinito globale.

In questo modo la configurazione dell'API (URL di base, intestazioni di autenticazione) viene centralizzata in un unico punto, senza ripeterla in ogni chiamata all'hook.

Il modello classico utilizza useEffect + useState per gestire manualmente gli stati di caricamento, dati ed errore. SWR sostituisce tutto questo con una singola chiamata a un hook che gestisce automaticamente caching, deduplicazione, aggiornamento in background e nuovi tentativi in caso di errore.

La riduzione del codice è significativa: un componente tipico per il recupero dei dati passa da oltre 20 righe a 3 righe.

La chiave identifica univocamente una richiesta. Utilizzi la stringa URL nei casi semplici. Per le richieste parametrizzate, utilizzi una chiave array: [url, params], dove params è un oggetto o una stringa stabile. null disabilita la richiesta.

Una buona progettazione delle chiavi garantisce che le richieste correlate condividano le voci della cache e che quelle non correlate non entrino in conflitto.

SWR gestisce la revalidazione in modo intelligente: dedupingInterval (2 secondi per impostazione predefinita) impedisce l'avvio simultaneo di più revalidazioni se molti componenti vengono montati contemporaneamente. Entro la finestra di deduplicazione viene inviata una sola richiesta per chiave.

Questo previene i problemi di tipo thundering herd comuni negli alberi di componenti di grandi dimensioni, in cui molti componenti recuperano gli stessi dati.

SWR è sviluppato da Vercel, l'azienda che ha creato Next.js, e l'integrazione è perfetta. getServerSideProps o getStaticProps possono precaricare i dati e SWR utilizza quel valore precaricato per l'hydration sul client.

In questo modo si ottiene HTML iniziale renderizzato sul server con revalidazione automatica lato client al montaggio, combinando i vantaggi di SSR e SWR.

Quale delle seguenti azioni NON attiva la revalidazione di SWR per impostazione predefinita?

SWR implementa la strategia Stale-While-Revalidate: fornisce immediatamente i dati memorizzati nella cache, esegue la revalidazione in background e aggiorna l'interfaccia quando arrivano dati aggiornati. Attiva la revalidazione quando la finestra torna in primo piano, quando la connessione viene ripristinata, quando viene chiamato mutate e durante il polling. La cache globale deduplica le richieste tra i componenti e la funzione fetcher è completamente sostituibile.

Questo modello semplifica notevolmente il codice per il recupero dei dati, offrendo al contempo prestazioni percepite più elevate.