React 19.3 a React 18: co naprawdę zmieniło się dla zespołu produktowego

React 19.3 ukazał się 9 września 2026 roku. Większość omówień premier przypomina listę funkcji; ja czytam je jak listę kodu do usunięcia. W porównaniu z React 18 — wciąż używanym w wielu aplikacjach produkcyjnych — linia 19 dotyczy mniej nowej składni, a bardziej porzucenia obejść pisanych przez każdy zespół od nowa: maszyn stanów formularzy, wrapperów forwardRef, memo wszędzie i sprawdzania typeof window.

React 19.0 położył podwaliny. Actions i useActionState zastąpiły ręcznie składany zestaw isPending / error / data w każdym formularzu. useOptimistic zmienił optymistyczny interfejs w hook zamiast reducera. use() odczytuje promise lub context podczas renderowania, także warunkowo. ref stał się zwykłym propem, więc forwardRef należy już do przeszłości; <Context> może sam pełnić rolę providera; <title> i <meta> trafiają do head z dowolnego komponentu. Zmiana miała też cenę: zniknęły string refs, legacy context, ReactDOM.render i propTypes w komponentach funkcyjnych. Aplikacja React 18 ze starymi zależnościami wymaga więc rzeczywistej migracji, nie tylko zmiany numeru wersji.

React 19.2 i React Compiler 1.0 zmieniły sposób pracy. <Activity mode="hidden"> utrzymuje kartę lub następną stronę wraz ze stanem w stanie zamontowanym, jednocześnie wstrzymując efekty — dawniej próbowaliśmy to naśladować przez display: none i nadzieję. useEffectEvent kończy spór z regułą exhaustive-deps: efekt reaguje na roomId, a callback po prostu odczytuje najnowszy motyw. Częściowe prerenderowanie (prerender, potem resume) pozwala wysłać statyczny szkielet z CDN, gdy część dynamiczna ładuje się strumieniowo. Compiler sprawił też, że większość ręcznych wywołań useMemo, useCallback i React.memo stała się zbędna. Zostawiam je, gdy biblioteka potrzebuje tożsamości referencyjnej, ale nie dodaję już odruchowo.

React 19.3 dotyczy animacji i granic DOM. <ViewTransition> jest już stabilny: obejmujemy element, oznaczamy aktualizację przez startTransition, a przeglądarka animuje pojawianie się, znikanie i współdzielone elementy. addTransitionType pozwala „next” i „previous” przesuwać się w różnych kierunkach w ramach tej samej aktualizacji stanu. Fragment refs udostępniają focus(), observeUsing() dla IntersectionObserver i pomiary grupy sąsiednich elementów bez dodatkowego div-a. use(browser()) z react-dom zastępuje sprawdzenie typeof window !== "undefined": komponent zawiesza się na serwerze, pokazuje fallback Suspense, a po hydratacji renderuje się po stronie klienta. Server Components mogą renderować <Context value> bezpośrednio, bez pliku providera z „use client”; react-dom przekazuje też obiekty Trusted Types zamiast zamieniać je na ciągi znaków, dzięki czemu React współpracuje ze ścisłą CSP i require-trusted-types-for.

Różnicę widać w importach. W React 18 formularz ze stanem oczekiwania, optymistyczną aktualizacją i animowaną listą oznaczał trzy biblioteki oraz własny hook; w 19.3 wystarczają useActionState, useOptimistic i <ViewTransition> z samego Reacta. W 18 „renderuj tylko po stronie klienta” oznaczało flagę mounted i przesunięcie układu; teraz to jedna linia i granica Suspense. W 18 wydajność wymagała dyscypliny w stosowaniu memo; dziś Compiler i React Performance Tracks w Chrome DevTools pokazują, co faktycznie zablokowało klatkę.

Nie przechodziłbym z 18 do 19.3 jednym pull requestem w produkcie obsługującym pieniądze. Mój celowo nudny plan: najpierw 18.3, by zobaczyć ostrzeżenia o wycofywanych elementach; potem 19 z oficjalnymi codemodami; następnie test Compiler na jednej trasie za flagą; nowe API dopiero tam, gdzie usuwają kod. Sam 19.3 jest addytywny — w ogłoszeniu nie ma zmian łamiących zgodność — ale komunikaty bezpieczeństwa dotyczące Server Components z grudnia 2025 przypominają, że wersje poprawkowe są równie ważne jak główne. Jeśli aplikacja nadal działa na 18, wyślij mi package.json i trzy najważniejsze ekrany. Odpowiem kolejnością aktualizacji i listą kodu, który będzie można usunąć.