Nel 2024 scegliere "come fetcho dati in React" è ancora una domanda con tre risposte serie: TanStack Query (ex React Query), SWR, RTK Query. Tre filosofie diverse. Vediamole come le applichiamo.
TanStack Query 5
La nostra prima scelta nel 90% dei progetti React. Il pattern queryKey + queryFn è semplice, le devtools sono fenomenali, le mutation con onSuccess/onError aderiscono al modo in cui pensiamo i form. La 5 ha portato suspense-mode stabile e tipi infinitamente migliorati.
SWR
Più leggera, meno opinionata, ottima per app dove il fetching è semplice (lista + dettaglio + qualche mutation). Per noi è la scelta quando il progetto è piccolo o quando c'è già un ecosistema Vercel-centrico (Next.js + SWR funziona benissimo).
RTK Query
Parte di Redux Toolkit. La forza è quando l'app già usa Redux per altro: in quel caso, integrare un altro client è ridondante. Per app nuove preferiamo evitare Redux di default — il bundle e la complessità non sono giustificati nella maggior parte dei casi.
Matrice di decisione
| Caso | Scelta |
|---|---|
| App nuova, fetching complesso, molti form | TanStack Query |
| Sito Next.js semplice, pochi endpoint | SWR (o niente, basta Server Actions) |
| App enterprise legacy con Redux | RTK Query |
| App con offline-first stringente | TanStack Query + persister |
Pattern che usiamo sempre
- Query key gerarchiche:
['blog', 'posts', { status: 'published' }]per invalidation chirurgica. - Optimistic update per le mutation che toccano liste visibili.
- Stale time configurato per intent: 30s per dashboard, 5min per cataloghi.