Jak Redux się zmienił i dlaczego wciąż dodaje się go do nowych projektów

Pamiętasz czasy, gdy prosty licznik Redux wymagał tworzenia trzech osobnych plików, deklarowania tuzina stałych i pisania ogromnego switch-case w reducerze? Z tego powodu tysiące deweloperów zaczęło nienawidzić tej biblioteki. Ale Redux nie jest już tym, czym był w 2015 roku.

Deweloperzy w porę rozpoznali problem i wydali Redux Toolkit (RTK). Dziś stał się standardem pracy z biblioteką i usunął prawie wszystko, za co Redux był wcześniej krytykowany.

Dlaczego w ogóle potrzebujesz globalnego menedżera stanu

W małych aplikacjach React możesz łatwo poradzić sobie z regularnym przekazywaniem props lub wbudowanym React Context. Problemy zaczynają się, gdy projekt rośnie. Gdy dane z jednego formularza muszą jednocześnie aktualizować pasek boczny, nagłówek strony i wysyłać analitykę, łańcuch props zamienia się w chaos.

Redux przechowuje stan aplikacji w jednym obiekcie (store). Nie zmieniasz tego obiektu bezpośrednio. Zamiast tego wysyłasz akcję, a czyste funkcje, reducery, obliczają nowy stan na podstawie starego.

To podejście daje wyraźną przewidywalność. Jeśli coś się zepsuje w aplikacji, przez Redux DevTools możesz zobaczyć pełną historię zmian stanu i przewinąć czas, śledząc działania użytkownika krok po kroku.

Jak Redux Toolkit ułatwił życie

Wcześniej, aby zaktualizować pojedyncze pole, musiałeś ręcznie śledzić niezmienność obiektów, tworząc niewygodne spready.

Redux Toolkit ma wbudowany Immer. Teraz kod wewnątrz reducerów piszesz tak, jakbyś bezpośrednio mutował stan, a biblioteka automatycznie konwertuje to na bezpieczną niezmienną aktualizację.

Spójrzmy na podstawowy przykład licznika:

import { createSlice, configureStore } from '@reduxjs/toolkit'

const counterSlice = createSlice({
  name: 'counter',
  initialState: {
    value: 0
  },
  reducers: {
    incremented: state => {
      // Immer улавливает "мутацию" и создает новое состояние
      state.value += 1
    },
    decremented: state => {
      state.value -= 1
    }
  }
})

export const { incremented, decremented } = counterSlice.actions

const store = configureStore({
  reducer: counterSlice.reducer
})

store.subscribe(() => console.log(store.getState()))

store.dispatch(incremented()) // { value: 1 }
store.dispatch(incremented()) // { value: 2 }
store.dispatch(decremented()) // { value: 1 }

Brak osobnych plików z typami akcji. Funkcja createSlice utworzyła zarówno reducer, jak i generatory akcji.

Kiedy Redux jest potrzebny, a kiedy lepiej się bez niego obejść

Twórca biblioteki Dan Abramov napisał „You Might Not Need Redux" lata temu. Ta rada jest nadal aktualna.

Redux przydaje się w konkretnych sytuacjach:

• Jest dużo danych, które aktywnie zmieniają się w czasie i są używane w różnych częściach aplikacji.
• Logika aktualizacji stanu jest złożona lub wymaga ścisłego sekwencjonowania.
• Potrzebujesz wygodnego debugowania z przezroczystą historią wszystkich zdarzeń.
• Wielu ludzi pracuje w zespole i wymagany jest jeden jasny wzorzec obsługi danych.

Jeśli masz prostą aplikację, gdzie dane muszą być przekazane tylko kilka poziomów w dół, wciąganie Redux tutaj nie jest tego warte. Dodatkowe abstrakcje tylko skomplikują kod.

Szybki start

Najłatwiejszy sposób na uruchomienie projektu to Vite i gotowy szablon Redux Toolkit z TypeScript:

npx degit reduxjs/redux-templates/packages/vite-template-redux my-app

Dla Next.js jest gotowy szablon od Vercel:

npx create-next-app --example with-redux my-app

Jeśli dodajesz bibliotekę do istniejącego projektu, wystarczy zainstalować dwa pakiety:

npm install @reduxjs/toolkit react-redux

Podsumowanie

Rdzeń Reduxa waży około 2 KB. Biblioteka dawno minęła erę nieskończonego boilerplate'u. W połączeniu z Redux Toolkit otrzymujesz ścisłe i przewidywalne narzędzie do zarządzania stanem, które świetnie sprawdza się w dużych projektach.