Quando inizi a usare React, gli hook sembrano ovunque.
Liste infinite, tutorial che ne usano dieci insieme, esempi che ti fanno pensare:
“Se non li conosco tutti, non sto davvero usando React.”
È falso.
Ed è uno dei motivi principali per cui molti sviluppatori si perdono inutilmente.
La verità è semplice:
👉 React richiede pochissimi hook per essere usato bene.
Il resto è contesto, maturità del progetto o overengineering.
Il problema non sono gli hook, è l’ansia da completezza
Chi arriva da HTML, CSS o JavaScript “classico” tende a fare questo errore:
- vuole capire tutto subito
- studia API prima di avere problemi reali
- usa hook perché “si fa così”
Ma React non premia chi conosce più hook.
Premia chi prende decisioni semplici sullo stato e sul flusso dei dati.
Questo è coerente con l’approccio spiegato nella documentazione ufficiale quando si introduce il pensare in React: prima capire il modello, poi gli strumenti.
Gli unici hook davvero fondamentali all’inizio
Se stai costruendo interfacce standard, questi hook ti bastano per molto tempo.
useState
È il cuore di React.
Serve per:
- stato locale
- input controllati
- toggle
- UI state
Se non hai chiaro quando usare useState, il problema non è il framework, è il modello mentale.
👉 La maggior parte dei problemi di React nasce da troppo stato, non da poco.
useEffect (ma con cautela)
useEffect è anche l’hook più abusato.
Serve per:
- side effects
- fetch di dati
- integrazioni esterne
Non serve per:
- sincronizzare stato
- “aggiustare” il rendering
- replicare lifecycle complessi
Se useEffect diventa la colla che tiene tutto insieme,
stai coprendo un problema architetturale.
Questo è uno dei motivi per cui molti lo trovano “confuso”: lo incontrano quando il design è già fragile.
useContext (solo quando smetti di passare props a cascata)
useContext ha senso quando:
- il prop drilling diventa rumoroso
- più componenti lontani leggono gli stessi dati
- il contesto è davvero condiviso
Non è un sostituto di useState.
È solo un modo per distribuire lo stato, non per crearne di nuovo.
Hook che puoi tranquillamente ignorare all’inizio
Qui è dove molti perdono tempo.
useReducer
Potente, sì.
Necessario subito? No.
Ha senso quando:
- la logica di stato è complessa
- le transizioni sono molte
- vuoi esplicitare gli eventi
Se lo usi per “ordine mentale”, stai anticipando complessità che forse non arriverà.
useMemo e useCallback
Questi hook non servono per scrivere React migliore.
Servono per ottimizzare React che già funziona.
Usarli troppo presto:
- rende il codice più verboso
- nasconde problemi reali
- complica la lettura
Se il tuo primo pensiero è “devo memoizzare”, probabilmente stai ottimizzando qualcosa che non è un problema.
Hook personalizzati
Gli hook custom non sono un obiettivo.
Sono una conseguenza.
Hanno senso quando:
- stai duplicando logica
- il comportamento è chiaro
- il flusso è stabile
Se li crei “per pulizia”, rischi solo di astrarre troppo presto.
Una regola semplice che funziona quasi sempre
Prima di introdurre un nuovo hook, chiediti:
“Questo risolve un problema reale che ho adesso?”
Se la risposta è:
- “no, ma potrebbe servire” → aspetta
- “lo fanno tutti” → ignora
- “ora il codice è più chiaro” → forse sì
React diventa caotico quando:
- accumuli strumenti
- anticipi problemi
- moltiplichi concetti
Diventa semplice quando:
- lo stato è chiaro
- il flusso è leggibile
- gli hook sono pochi
Perché meno hook = più controllo
Ogni hook che aggiungi:
- introduce un livello mentale
- richiede disciplina
- aumenta il costo di manutenzione
Se non ne senti il bisogno, non aggiungerlo.
Questo approccio è coerente anche con le linee guida ufficiali di React sulla gestione degli effetti e dello stato, presenti nella documentazione MDN e su react.dev, dove l’enfasi è sempre sulla chiarezza prima dell’ottimizzazione.
Conclusione: gli hook non sono il punto, le decisioni sì
React Hooks non servono a scrivere codice più “moderno”.
Servono a gestire il cambiamento in modo dichiarativo.
Se:
- usi pochi hook
- capisci perché li usi
- rimandi l’ottimizzazione
React diventa prevedibile.
Se invece:
- accumuli hook
- li usi “per sicurezza”
- anticipi problemi
React diventa rumoroso.
👉 Non serve conoscere tutti gli hook.
Serve sapere quando NON usarli.
Vuoi continuare il percorso?
A questo punto il cluster è maturo per un passaggio chiave:
come pensare l’architettura React senza trasformarla in MVC travestito.
👉 (in arrivo) Perché React non è MVC (e smettere di trattarlo come tale)
