Zarządzanie stanem w React

Co to jest Zustand i czym różni się od Redux?

Zustand: minimalistyczna biblioteka do zarządzania stanem w React (Poimandres, 2019). Filozofia: state management nie musi być skomplikowany. Redux: powszechnie uznawany za zbyt verbose. Actions, Reducers, Selectors, Middleware, Thunks — wiele boilerplate. Zustand: jeden store, jedna funkcja create(), dostęp przez hook. const useStore = create((set) => ({bears: 0, addBear: () => set(state => ({bears: state.bears + 1}))}))). Użycie: const bears = useStore(state => state.bears). const addBear = useStore(state => state.addBear). Zalety Zustand: zero boilerplate. Działa poza React (vanilla JS). Automatyczna selektywna subskrypcja (component rerenderuje tylko gdy jego selektor zmienia się). Middleware wbudowane (immer, persist, devtools). TypeScript first. Bundle size: 8KB gzipped. Porównanie z Redux: Redux Toolkit (RTK) też redukuje boilerplate vs vanilla Redux. RTK + RTK Query to kompleksowy framework. Zustand prostszy dla małych-średnich projektów. Kiedy Zustand: globalny stan który nie pasuje do React Query (nie API data). UI state (sidebar open, theme, cart). Kiedy Redux/RTK: duże enterprisey aplikacje. Zaawansowane middleware wymagane. Ecosystem RTK Query.

Jotai — atomowy model zarządzania stanem inspirowany Recoil?

Jotai: atomowy state manager dla React (Poimandres). Inspirowany Recoil (Facebook) ale bez boilerplate. Atom: najmniejsza jednostka stanu. const countAtom = atom(0). Użycie: const [count, setCount] = useAtom(countAtom). Jak useState ale globalnie dostępny. Derived atoms: const doubleAtom = atom(get => get(countAtom) * 2). Obliczony z innego atomu. Writable derived atom: atom(get => ..., (get, set, update) => set(countAtom, update)). Async atoms: atom(async get => await fetchUser(get(userIdAtom))). Automatyczne Suspense. Zalety Jotai: granularna subskrypcja — component rerenderuje tylko gdy jego atom zmieni się. Brak Provider (opcjonalny). Brak selectorów — atom jest selectorem. React Suspense integration. Brak boilerplate. TypeScript first. Atom Family: atomFamily(id => atom(fetchById(id))). Atoms per item. Efektywne. Jotai vs Zustand: Jotai — atom per piece of state, granular. Zustand — jeden store ze wszystkim. Jotai lepszy gdy wiele niezależnych pieces of state. Zustand lepszy gdy state jest powiązany. Recoil vs Jotai: Recoil — Facebook, większy, RecoilRoot wymagany. Jotai — mniejszy, szybszy, no provider needed. Jotai często preferowany nad Recoil. Valtio: proxy-based (Poimandres). Mutowalne przez proxy.

Redux Toolkit (RTK) — jak używać w 2024?

Redux Toolkit: oficjalny sposób pisania Redux od 2019. Eliminuje boilerplate. Kluczowe API: configureStore: tworzy store z middleware (redux-thunk, devtools). createSlice: kombinuje reducer + actions w jednym miejscu. Immer wbudowany — możesz 'mutować' stan. createAsyncThunk: obsługa async actions. createEntityAdapter: normalizacja danych (CRUD helpers). Przykład slice: const counterSlice = createSlice({name: 'counter', initialState: {value: 0}, reducers: {increment: state => {state.value += 1}, decrement: state => {state.value -= 1}}}). RTK Query: wbudowane zarządzanie API calls. Automatyczne caching. Cache invalidation. Optimistic updates. Polling. Zastępuje React Query dla Redux-based projektów. createApi: define endpoints (query i mutation). Generuje hooki: useGetUsersQuery(), useCreateUserMutation(). Selektory: createSelector (Reselect wbudowany). Memoizacja selektorów. Kiedy Redux Toolkit vs inne: duże aplikacje enterprise. Potrzebujesz RTK Query. Masz duży team z Redux doświadczeniem. Potrzebujesz zaawansowanego middleware. Kiedy Zustand/Jotai zamiast RTK: nowy projekt. Mały-średni rozmiar. Chcesz mniej boilerplate. Nie potrzebujesz RTK Query (używasz TanStack Query). Migracja z Redux do RTK: stopniowo — zacznij od configureStore, potem createSlice.

React Context API — kiedy używać zamiast zewnętrznych bibliotek?

Context API: wbudowane w React rozwiązanie dla global state. createContext(), useContext(), Provider. Kiedy Context wystarczy: rzadko zmieniające się dane — theme, locale, user session, auth. Dane używane przez wiele komponentów w drzewie. Unikaj dla: często zmieniający się stan — każda zmiana rerenderuje wszystkich consumerów. Duży performance hit przy częstych aktualizacjach. Problem z Context rerenderami: context.Provider rerenderuje wszystkich consumerów gdy value zmieni się. Nawet jeśli komponent używa tylko jednej części contextu. Rozwiązanie 1: podziel context na mniejsze (AuthContext, ThemeContext, UserContext). Rozwiązanie 2: use-context-selector (biblioteka) — subskrybuj tylko część contextu. Rozwiązanie 3: React.memo + useMemo dla value. Context vs Zustand: Context — dla rzadkich zmian, brak zależności. Zustand — częste aktualizacje, granularna subskrypcja. useReducer + Context: alternatywa dla Redux w małych projektach. reducer zarządza logiką. Context propaguje state. Brak zewnętrznych zależności. Server State vs Client State: Server State (API data) -> React Query / TanStack Query. Client State (UI, user input) -> Zustand / Jotai / Context. Nie używaj Zustand dla API data (React Query jest lepszy). Nie używaj React Query dla UI state.

Jak wybrać właściwą bibliotekę state management w 2024?

Decision tree: czy to server state (dane z API)? Tak -> TanStack Query (React Query). Nie -> kontynuuj. Czy stan jest używany w całej aplikacji? Nie -> useState/useReducer lokalnie. Tak -> kontynuuj. Jak złożona jest aplikacja? Prosta (<10 screens) -> Context API. Średnia -> Zustand. Duża/Enterprise -> Zustand lub Redux Toolkit. Specyficzne wymagania -> patrz niżej. Potrzebujesz atomowego modelu? Jotai lub Recoil. Potrzebujesz proxy/mutacji? Valtio. Potrzebujesz RTK Query? Redux Toolkit. Nowe projekty w 2024: Zustand — default choice dla client state. TanStack Query — default choice dla server state. Kombinacja: Zustand (client) + TanStack Query (server). Skaluje się dobrze. Minimal boilerplate. Zustand best practices: nie przechowuj server state w Zustand (duplication). Podziel store na slice'y. useShallow dla obiektów (zapobiegnie zbędnym rerenderom). Immer middleware dla złożonych aktualizacji. Persist middleware dla localStorage. Devtools middleware dla debugging. Jotai best practices: używaj atomFamily dla list items. async atoms z Suspense. Atom debugger w devtools. Normalizuj dane podobnie jak w entity adapters.

Wyślij zapytanie