Kiedy Context jest dobrym rozwiązaniem stanu, a kiedy nie?

Question

Accepted Answer

**Context API** React umożliwia udostępnianie wartości całemu drzewu komponentów bez prop drilling. To świetne rozwiązanie dla **rzadko zmieniających się, powszechnie udostępnianych** danych — ale nie jest *pełnym* rozwiązaniem do zarządzania stanem i ma pułapkę ponownego renderowania dla często zmieniającego się stanu. ## Kiedy Context świeci ```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 ``` ## Pułapka: każdy konsument renderuje się ponownie przy KAŻDEJ zmianie ```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 ``` Kiedy zmienia się wartość kontekstu, **wszystkie** komponenty konsumujące ten kontekst renderują się ponownie — niezależnie od tego, czy używają zmienionej części. W przypadku często aktualizowanego stanu powoduje to problemy z wydajnością. Context nie ma wbudowanej selektywnej subskrypcji. ## Łagodzenie i alternatywa ```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 ``` Biblioteki stanu (Zustand, Redux, Jotai) rozwiązują problem ponownego renderowania za pomocą **selektywnych subskrypcji** — komponenty subskrybują tylko części, które używają, i renderują się ponownie tylko wtedy, gdy te się zmieniają: ```js const count = useStore(s => s.count); // re-renders ONLY when count changes ``` ## Context nie jest menedżerem stanu ```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. ``` ## Dlaczego to ważne Znajomość słabych i mocnych stron Context — i jego ograniczeń — zapobiega dwóm typowym błędom: prop drillingowi rzeczy, które powinny być w Context, i umieszczaniu w Context stanu o wysokiej częstotliwości zmian (powodując renderowanie całej aplikacji). Reguła: Context dla **rzadko zmieniających się, powszechnie udostępnianych** wartości (motyw, użytkownik, lokalizacja); dedykowany store z selektywną subskrypcją dla **często zmieniającego się lub dużego** stanu udostępnianego. Zrozumienie, że Context dystrybuuje stan, ale go nie zarządza, wyjaśnia, kiedy wystarczy, a kiedy potrzebujesz czegoś więcej.