Quando Context è una buona soluzione di state e quando non lo è?

Question

Accepted Answer

L'**API Context** di React ti permette di condividere un valore con un intero sottobero di componenti senza prop drilling. È ottima per dati **a bassa frequenza, ampiamente condivisi** — ma non è una soluzione completa di gestione dello stato e ha una trappola di re-render per lo stato che cambia frequentemente. ## Quando Context brilla ```jsx const ThemeContext = createContext("light"); function App() { const [theme, setTheme] = useState("light"); return ( {/* any descendant can read theme — no prop drilling */} ); } ``` ```text Good fits (data that's read widely but changes rarely): ✓ Theme (dark/light) ✓ Current user / auth ✓ Locale / i18n ✓ App-wide config or feature flags ``` ## La trappola: ogni consumer esegue il re-render a QUALUNQUE cambiamento ```jsx // ❌ a context value that changes often re-renders ALL consumers const AppContext = createContext(); // value = { user, cart, notifications, ...everything } // → updating ONE field re-renders EVERY component using the context ``` Quando il valore del context cambia, **tutti** i componenti che lo consumano eseguono il re-render — indipendentemente dal fatto che usino la parte che è cambiata. Per lo stato che si aggiorna frequentemente, questo causa problemi di performance. Context non ha una sottoscrizione selettiva integrata. ## Mitigazioni e l'alternativa ```text ✓ Split into multiple focused contexts (ThemeContext, UserContext separately) ✓ Memoize the value object (useMemo) so it doesn't change identity needlessly ✗ But for high-frequency or large shared state → use a real store ``` Le librerie di state (Zustand, Redux, Jotai) risolvono il problema del re-render con **sottoscrizioni selettive** — i componenti si sottoscrivono solo alle slice che utilizzano e eseguono il re-render solo quando quelle cambiano: ```js const count = useStore(s => s.count); // re-renders ONLY when count changes ``` ## Context non è un state manager ```text Context = a TRANSPORT mechanism (passes a value down), NOT state management itself. You still need useState/useReducer to hold the state; Context just distributes it. ``` ## Perché è importante Conoscere il sweet spot di Context — e i suoi limiti — previene due errori comuni: il prop-drilling di cose che dovrebbero essere in Context, e mettere state ad alta frequenza in Context (causando re-render a livello di app). La regola: Context per valori **raramente mutevoli, ampiamente condivisi** (tema, utente, locale); uno store dedicato con sottoscrizioni selettive per stato **frequentemente mutevole o ampio**. Comprendere che Context distribuisce lo stato ma non lo gestisce chiarisce quando è sufficiente e quando hai bisogno di più.