import { create } from 'zustand';
interface CartState {
items: string[];
addItem: (item: string) => void;
clearCart: () => void;
}
// Un store global curat, fără Provider-ul din Context API
export const useCartStore = create<CartState>((set) => ({
items: [],
addItem: (item) => set((state) => ({ items: [...state.items, item] })),
clearCart: () => set({ items: [] }),
}));Să fim sinceri: ne place să ne complicăm viața ca developeri. Am văzut echipe care bagă Redux Toolkit pentru un amărât de dropdown și altele care se chinuie cu 15 useState-uri trimise prin 5 niveluri de componente.
De când a apărut Zustand, a devenit preferatul meu pentru state management global în React. Dar asta nu înseamnă că useReducer e mort. Ba chiar aș zice că e extrem de subestimat pentru ce a fost gândit să facă: starea locală complexă.
Când folosesc useReducer și de ce nu e depășit
Am avut acum un an un proiect cu un formular gigant de onboarding. Aveam vreo 24 de câmpuri, cu validări condiționate, pași dinamici și vreo 5 apeluri API intermediare. Dacă puneam useState pentru fiecare chestie, codul devenea de necitit. Dacă foloseam un store global ca Zustand, poluam starea globală cu date temporare care nu interesau pe nimeni în afara acelui formular.
Aici useReducer e rege. Îți dă o structură clară, predictibilă, localizată exact acolo unde se întâmplă acțiunea.
Trade-off-ul sincer: useReducer e genial pentru coeziune locală, dar devine un coșmar dacă trebuie să trimiți acele date către o componentă dintr-o altă ramură a arborelui React. Da, poți să-l combini cu useContext, dar la fiecare schimbare de stare vei declanșa re-randări în lanț pentru toți consumatorii. Am pățit asta pe un dashboard cu grafice în timp real și a trebuit să rescriem tot pentru că frame-rate-ul scăzuse la 15 FPS.
Zustand: Când ai nevoie de un creier global
Dacă ai date care trebuie accesate de oriunde (user session, temă, coș de cumpărături, setări de filtrare globale), lasă useContext și useReducer în pace. Zustand e răspunsul.
La o aplicație SaaS la care lucrez (avem cam 8.000 de utilizatori activi zilnic), aveam un boilerplate imens cu Redux. Am trecut totul pe Zustand în două weekenduri. Am eliminat peste 400 de linii de cod de tip actions/reducers/types și am economisit timp la build-uri.
De ce îmi place? Pentru că nu are nevoie de un Provider la nivel de root (deci nu re-randează tot arborele când se schimbă ceva) și folosește selectoare extrem de curate.
Zustand excelează la performanță datorită acestor selectoare. Dacă schimbi doar un câmp din store, doar componentele care ascultă de acel câmp specific se vor re-randa. În React Context, trebuia să folosești tehnici complicate de memoizare ca să obții același comportament.
Care e capcana cu Zustand? Fiind atât de simplu de folosit, riști să muți absolut toată starea în el. Am văzut proiecte unde starea unui amărât de modal local era ținută în Zustand. Asta duce la un cod greu de urmărit și strică complet ideea de componente reutilizabile.
Cum facem alegerea?
Regula mea de aur e simplă:
- Starea e folosită doar de o pagină sau un formular complex? ->
useReducer. Rămâne local, moare când componenta se demontează. - Starea e folosită în mai multe pagini sau widget-uri independente? ->
Zustand.
Voi cum procedați? Mai folosește cineva Redux clasic sau ați trecut toți pe variante mai lightweight?