React — deklaratywne komponenty i przewidywalny stan interfejsu

React jest tak powszechny, że przestał być tematem. Nikt nie pisze wpisów „czym jest React", bo wszyscy wiedzą, a poradniki są w internecie tysiącami. Problem polega na tym, że większość tych poradników opisuje React sprzed trzech lat — a w ciągu ostatnich osiemnastu miesięcy zmieniły się w nim trzy rzeczy, z których każda osobno wystarczyłaby na osobny wpis: kto jest właścicielem projektu, jak się go optymalizuje i jak się zakłada nowy projekt.

Ten wpis nie jest wprowadzeniem do Reacta. Jest przeglądem tego, co się w nim zmieniło i co z tego wynika dla zespołu, który utrzymuje aplikacje w Laravelu z frontem w Reakcie na Inertii — czyli dla nas i dla większości agencji pracujących w tym stacku. Bo część nowości Reacta dotyczy nas bezpośrednio, część nie dotyczy wcale, a jedna kategoria to zmiany bezpieczeństwa, o których trzeba wiedzieć, zamiast zakładać.

Repozytorium zmieniło adres

Najprostszy dowód, że coś się stało: zapytanie API GitHuba o facebook/react zwraca dziś przekierowanie. Kanoniczna lokalizacja to github.com/react/react — projekt ma własną organizację i nie leży już w przestrzeni nazw Meta.

Stan na 17 września 2026, z API GitHuba:

249 675 gwiazdek i 51 314 forków — jeden z trzech najpopularniejszych projektów na GitHubie w ogóle,
repozytorium założone 24 maja 2013, czyli trzynaście lat historii. Licencja MIT,
ostatni commit z 9 września 2026, 1347 otwartych zgłoszeń,
najnowsze wydanie 19.2.8 z 21 lipca 2026.

Ta ostatnia data wymaga komentarza, bo pokazuje coś nieoczywistego o polityce wsparcia. Tego samego dnia — 21 lipca 2026 — wyszły trzy wydania naraz: 19.2.8, 19.1.9 i 19.0.8. Wcześniej, 1 czerwca, również trzy: 19.2.7, 19.1.8 i 19.0.7. Zespół utrzymuje równolegle trzy linie wersji minor i łata je jednocześnie. W praktyce oznacza to, że aktualizacja bezpieczeństwa nie wymusza skoku na najnowszy minor — ale też że warto wiedzieć, na której linii siedzi nasz projekt, bo poprawka przychodzi tam, a nie „w najnowszym Reakcie".

React należy teraz do fundacji

Chronologia, według wpisów na blogu projektu:

7 października 2025 — ogłoszenie planów utworzenia React Foundation wraz z nową strukturą zarządzania technicznego,
24 lutego 2026 — React Foundation oficjalnie startuje, hostowana przez Linux Foundation. Meta przekazuje fundacji projekty: React, React Native i JSX.

Dla zespołu podejmującego decyzje technologiczne to jest zmiana istotna i warto ją nazwać precyzyjnie, bo łatwo ją przecenić albo zignorować. Licencja się nie zmienia — React był i jest na MIT. Zmienia się zarządzanie: kierunek rozwoju i prawa do znaków towarowych przechodzą z jednej korporacji do fundacji działającej w ramach Linux Foundation, z formalną strukturą zarządzania technicznego.

Dlaczego to ma znaczenie? Bo historia dała już przykład, jak wygląda ryzyko jednego właściciela. React był początkowo licencjonowany na BSD z osobną klauzulą patentową, którą Apache Software Foundation uznała w 2017 roku za niedopuszczalną dla swoich projektów. Kilka tygodni później Facebook przelicencjonował React na MIT — ale przez ten czas w dziesiątkach firm odbywały się rozmowy o migracji na Vue. Przeniesienie projektu do fundacji zdejmuje tę klasę ryzyka: pojedyncza firma nie może już samodzielnie zmienić warunków korzystania.

To jest najlepszy argument, jaki React zebrał w ostatnich latach na rzecz wyboru go jako fundamentu na następną dekadę — i jednocześnie argument, którego nie znajdzie się w żadnym poradniku technicznym, bo nie dotyczy kodu.

React Compiler 1.0 — koniec ręcznej memoizacji

Zmiana o największym wpływie na codzienne pisanie kodu. 7 października 2025 wyszedł React Compiler w wersji 1.0 — pierwsze stabilne, przeznaczone do produkcji wydanie, dla Reacta i React Native.

Co robi: analizuje komponenty i hooki na etapie budowania i zapewnia, że przy zmianie stanu przerenderowuje się tylko minimalna konieczna część. Innymi słowy — robi automatycznie to, co dotąd trzeba było robić ręcznie przez useMemo, useCallback i React.memo.

Skutek dla sposobu pisania kodu jest większy, niż sugeruje opis. Ręczna memoizacja miała trzy wady, które kompilator usuwa naraz:

Zaśmiecała kod. Komponent, w którym połowa linii to useCallback z tablicą zależności, jest trudniejszy do czytania niż ten sam komponent bez nich,
Była zawodna. Człowiek zapomina dopisać zależność albo dopisuje za dużo. Kompilator nie zapomina i nie przesadza,
Była stosowana pochopnie. Memoizacja ma koszt — porównania i pamięć. Ręcznie stosowano ją tam, gdzie „na wszelki wypadek", a nie tam, gdzie się opłaca.

Kompilator ma jednak warunek wstępny, który jest realnym kosztem wdrożenia w istniejącym projekcie: komponenty muszą przestrzegać Reguł Reacta. Kompilator to waliduje — i dlatego drugi element tego wydania jest równie ważny jak pierwszy.

Reguły przeszły do wtyczki lintera

Reguły lintowania oparte o kompilator przeniesiono do eslint-plugin-react-hooks, do presetów recommended i recommended-latest. Konsekwencja praktyczna: jeśli w projekcie jest osobny eslint-plugin-react-compiler, należy go usunąć i zaktualizować eslint-plugin-react-hooks do najnowszej wersji.

Aktualna linia wtyczki to 7.x, a wydanie 7.1.0 z kwietnia 2026 dodało wsparcie dla ESLint v10, pomijanie kompilacji dla plików niebędących kodem Reacta (co przyspiesza lintowanie) oraz lepsze wykrywanie ustawiania stanu w efektach i walidację referencji.

To jest kolejność, którą warto zapamiętać przy wdrażaniu kompilatora w starym projekcie: najpierw lint, potem kompilator. Wtyczka pokaże miejsca łamiące reguły — mutacje propsów, warunkowe wywołania hooków, ustawianie stanu w efekcie — a to są dokładnie te miejsca, w których kompilator albo się wycofa, albo zachowa się inaczej niż dotychczasowy kod.

Jak to wygląda w kodzie

Typowy komponent panelu administracyjnego napisany „poprawnie" według praktyk sprzed kompilatora:

function OrdersTable({ orders, currency, onSelect }) {
  const sorted = useMemo(
    () => [...orders].sort((a, b) => b.total - a.total),
    [orders],
  );

  const formatter = useMemo(
    () => new Intl.NumberFormat('pl-PL', { style: 'currency', currency }),
    [currency],
  );

  const handleSelect = useCallback(
    (id) => onSelect(id),
    [onSelect],
  );

  return (
    <table>
      {sorted.map((order) => (
        <Row
          key={order.id}
          order={order}
          label={formatter.format(order.total)}
          onSelect={handleSelect}
        />
      ))}
    </table>
  );
}

Z włączonym kompilatorem ten sam komponent pisze się tak:

function OrdersTable({ orders, currency, onSelect }) {
  const sorted = [...orders].sort((a, b) => b.total - a.total);
  const formatter = new Intl.NumberFormat('pl-PL', {
    style: 'currency',
    currency,
  });

  return (
    <table>
      {sorted.map((order) => (
        <Row
          key={order.id}
          order={order}
          label={formatter.format(order.total)}
          onSelect={onSelect}
        />
      ))}
    </table>
  );
}

Trzy hooki mniej, dwadzieścia linii mniej i — co ważniejsze — zero tablic zależności do utrzymania. Kompilator sam ustala, że sortowanie zależy od orders, a formatter od currency, i sam zapewnia, że Row nie przerenderuje się bez powodu. Nie jest to przy tym „mniej wydajny kod, który wygląda ładniej": to ten sam efekt, tylko wyliczony przez narzędzie, które nie pomyli się w zależnościach.

Warunek, który ten przykład spełnia i o którym trzeba pamiętać przy starym kodzie: [...orders], nie orders.sort(). Mutacja propsa złamałaby Reguły Reacta, a kompilator zakłada, że propsy są niemutowalne. To jest dokładnie ta klasa błędów, którą wyłapuje lint.

Ciekawostka z bieżących commitów: kompilator jest przepisywany w Ruście. W repozytorium widać commity oznaczone [rust-compiler] i osobną instrukcję publikowania crate'ów. Dla użytkownika to na razie nic nie zmienia poza obietnicą krótszych czasów budowania.

Co przyniosła wersja 19.2

Wydanie z 1 października 2025, wciąż najnowsza linia minor. Cztery rzeczy warte uwagi.

useEffectEvent — hook pozwalający wyciągnąć z efektu logikę niereaktywną. Rozwiązuje problem, który zna każdy, kto pisał efekty: potrzebujemy w środku efektu dostępu do aktualnej wartości, ale nie chcemy, żeby jej zmiana wywoływała ponowne uruchomienie efektu. Dotąd kończyło się to albo referencją w useRef, albo świadomym kłamstwem w tablicy zależności i wyciszonym ostrzeżeniem lintera. Teraz jest na to API.

<Activity> — komponent ukrywający i przywracający interfejs razem ze stanem wewnętrznym dzieci. Zespół pracował nad tym latami, co dokumentacja odnotowuje wprost. Praktyczne zastosowania: zakładki, które po powrocie nie tracą pozycji przewijania ani zawartości formularza, oraz przygotowywanie w tle widoku, który użytkownik prawdopodobnie otworzy.

Ślady wydajności Reacta — pojawiają się na osi czasu w panelu Performance przeglądarki. To jest zmiana w diagnostyce, której wartość docenia się przy pierwszym „dlaczego ta lista renderuje się sekundę": zamiast zgadywać, widać, co React robił i kiedy.

Wsadowe odsłanianie granic Suspense — React DOM grupuje teraz odsłanianie granic Suspense, tak jak przy renderowaniu po stronie klienta. Ma to znaczenie przy animowaniu pojawiania się treści i jest przygotowaniem pod zapowiadany komponent <ViewTransition>.

Do tego jedna zmiana mała i podstępna: format identyfikatorów z useId zmienił się dwukrotnie. W 19.1 z :r123: na «r123», żeby były poprawnymi selektorami CSS, a w 19.2 na wariant z podkreśleniem. Powód jest praktyczny — dwukropek wymagał ucieczki w selektorach i psuł naiwne wywołania querySelector. Jeśli gdziekolwiek w kodzie albo w testach opieraliśmy się na kształcie tych identyfikatorów, obie te zmiany to złamały.

Warto też odnotować, co przyniosła wersja 19.1 z 28 marca 2025, bo dotyczy codziennego debugowania: Owner Stack i API captureOwnerStack. To ślad stosu dostępny tylko w kompilacjach rozwojowych, pokazujący, które komponenty są bezpośrednio odpowiedzialne za wyrenderowanie danego komponentu — a to jest inna informacja niż zwykły stos komponentów, pokazujący hierarchię prowadzącą do błędu. Przy diagnozowaniu „skąd tu się w ogóle wziął ten komponent" różnica jest zasadnicza. Ta sama wersja rozszerzyła użycie granic Suspense na dowolne miejsce — klienta, serwer i hydratację — oraz usunęła React.act z kompilacji produkcyjnych.

Nowości 19.0, których wiele zespołów wciąż nie używa

React 19.0 wyszedł 5 grudnia 2024 i przyniósł zestaw API, które w naszym stacku działają w całości — a spora część projektów, które formalnie są „na Reakcie 19", nadal pisze kod jak na 18. Sześć rzeczy wartych nadrobienia:

ref jako props. Referencje można przekazywać jak zwykłe właściwości, co znosi potrzebę forwardRef. Każdy komponent opakowany dotąd tylko po to, żeby przepuścić referencję, może się z tego opakowania pozbyć,
Funkcje czyszczące dla referencji. Funkcja zwrócona z callbacku referencji jest wywoływana przy odmontowaniu komponentu. Koniec z ręcznym pilnowaniem nasłuchiwaczy podpiętych do węzła DOM,
<Context> jako dostawca. Zamiast <Context.Provider> wystarczy <Context>. Kosmetyka, ale zmniejsza ilość szumu w drzewie,
use() — czytanie zasobów w trakcie renderowania. Przyjmuje obietnicę (wtedy zawiesza komponent do rozwiązania) albo kontekst. Kluczowa różnica względem hooków: use() można wywołać warunkowo,
useOptimistic — aktualizacja stanu „na zapas", zanim operacja się zakończy, z automatycznym powrotem do wartości rzeczywistej po jej zakończeniu. Warto wiedzieć, że Inertia w wersji 3 ma własny mechanizm aktualizacji optymistycznych z automatycznym wycofaniem — więc w formularzach na Inertii to zwykle jego się używa, a useOptimistic zostaje dla stanu, który nie przechodzi przez wizytę Inertii,
useDeferredValue z wartością początkową. Podana wartość zostaje zwrócona przy pierwszym renderowaniu, a właściwa dochodzi w tle. Przydatne przy filtrach nad dużymi listami.

Osobna kategoria to API do wstępnego wczytywania zasobów: preinit, preload, prefetchDNS i preconnect. Pozwalają wyprowadzić wykrywanie fontów i innych zasobów z łańcucha wczytywania arkuszy stylów, a także przygotować zasoby pod przewidywaną nawigację. W aplikacji na Inertii, gdzie nawigacja jest przewidywalna (użytkownik z listy idzie do szczegółów), to jest niedoceniany sposób na skrócenie odczuwanego czasu przejścia.

Dwie rzeczy z 19.0 warto natomiast wyraźnie ominąć w naszym stacku, bo się dublują z Inertią: wsparcie dla metadanych dokumentu (React sam wynosi <title> i <meta> do sekcji <head>) oraz akcje formularzy przez atrybut action razem z useActionState i useFormStatus. Inertia ma do jednego komponent <Head>, a do drugiego useForm i komponent <Form>, zintegrowane z walidacją Laravela i z obsługą błędów po stronie serwera. Mieszanie obu mechanizmów w jednym formularzu kończy się dwoma źródłami prawdy o stanie wysyłki.

Co usunięto — lista, która boli przy aktualizacji

React 19 był wydaniem z realnymi zmianami łamiącymi zgodność i to jest najczęstszy powód, dla którego projekty siedzą jeszcze na 18. Zalecana droga to najpierw aktualizacja do 18.3.1, identycznej z 18.2 poza dodanymi ostrzeżeniami o wycofywanych API — dopiero potem skok na 19. Co zniknęło:

propTypes są ignorowane w milczeniu. Nie ostrzeżenie, nie błąd — po prostu przestają cokolwiek robić. Projekt polegający na nich do walidacji propsów traci ją bez żadnego sygnału. Zastępstwem jest TypeScript,
defaultProps dla komponentów funkcyjnych usunięte — do zastąpienia domyślnymi parametrami ES6. Komponenty klasowe nadal je mają, bo nie ma tam alternatywy,
Referencje w formie łańcucha znaków — usunięte, do migracji na callbacki,
ReactDOM.render i ReactDOM.hydrate — usunięte na rzecz createRoot i hydrateRoot. Podobnie unmountComponentAtNode (teraz root.unmount()) i findDOMNode (teraz referencje),
react-dom/test-utils — usunięte; act przeniesiono do pakietu react, reszta zniknęła. react-test-renderer jest wycofywany, a rekomendacją jest Testing Library,
Kompilacje UMD — usunięte. Wczytanie Reacta zwykłym znacznikiem <script> wymaga dziś CDN-u opartego o moduły ES,
Nowa transformacja JSX jest wymagana — to nie jest opcja, a warunek działania takich rzeczy jak ref w roli propsa,
Błędy w renderowaniu nie są ponownie rzucane. Niezłapane przez granicę błędów idą do window.reportError, złapane do console.error. Do dostosowania tego są nowe opcje onUncaughtError i onCaughtError przekazywane do createRoot i hydrateRoot — i to jest miejsce, w którym warto podpiąć własne raportowanie błędów,
StrictMode zachowuje się inaczej — useMemo i useCallback reużywają wyniki z pierwszego renderowania w drugim, a callbacki referencji są wywoływane podwójnie przy montowaniu.

Jest też zmiana, która przy aktualizacji pomaga zamiast przeszkadzać: błędy hydratacji są raportowane jako jeden komunikat z różnicą treści, zamiast serii nieczytelnych ostrzeżeń. Przy SSR na Inertii, gdzie rozjazdy hydratacji zdarzają się przy datach i formatowaniu liczb zależnym od strefy, to jest oszczędność liczona w godzinach.

Bezpieczeństwo: trzy podatności w Server Components

Ta część jest najważniejsza w całym wpisie i najczęściej pomijana, bo nie jest funkcją, o której się mówi na konferencjach. W grudniu 2025 na blogu projektu pojawiły się dwa wpisy o podatnościach:

3 grudnia 2025 — krytyczna podatność w React Server Components pozwalająca na nieuwierzytelnione zdalne wykonanie kodu. Poprawki wydano w wersjach 19.0.1, 19.1.2 i 19.2.1,
11 grudnia 2025 — dwie kolejne podatności w Server Components: odmowa usługi oraz ujawnienie kodu źródłowego, zgłoszone przez badaczy bezpieczeństwa.

Wniosek jest szerszy niż same numery wersji. React przestał być „tylko biblioteką widoku". Server Components to kod wykonywany na serwerze, z serializacją danych przechodzących przez granicę klient–serwer — i ma powierzchnię ataku serwera, nie przeglądarki. Nieuwierzytelnione zdalne wykonanie kodu w bibliotece frontendowej brzmi jak pomyłka kategorii, dopóki nie zauważymy, że ta biblioteka od dwóch lat wykonuje kod po stronie serwera.

Praktyczna konsekwencja dla każdego zespołu: aktualizacja Reacta jest teraz zadaniem bezpieczeństwa, nie tylko higieny zależności. Warto mieć w projekcie mechanizm, który o takich wydaniach informuje — bot aktualizujący zależności albo choćby subskrypcja bloga projektu.

Create React App jest wycofany

Zmiana z 14 lutego 2025, którą warto odnotować, bo wciąż spotyka się poradniki od niej zaczynające. Create React App został wycofany dla nowych aplikacji. Rekomendacja projektu to albo pełny framework, albo narzędzie budujące: Vite, Parcel lub RSBuild.

Dla nas ta zmiana jest bez znaczenia praktycznego — Inertia w Laravelu stoi na Vite od początku — ale ma znaczenie przy przyjmowaniu cudzego kodu i przy rekrutacji. Projekt zaczynający się od create-react-app pochodzi z innej epoki narzędziowej i ma przed sobą migrację.

Co z tego działa w stacku Laravel plus Inertia

Tu trzeba postawić granicę, bo połowa nowości Reacta z ostatnich dwóch lat dotyczy świata, w którym React jest warstwą serwerową — a w naszym stacku tę rolę pełni Laravel.

Czego nie używamy i nie potrzebujemy

Server Components — u nas komponentem serwerowym jest kontroler w Laravelu. Dane przychodzą propsami z Inertia::render(), a walidacja, autoryzacja i dostęp do bazy zostają w PHP, gdzie mamy polityki, reguły walidacji i Eloquenta,
Server Functions i Server Actions — ich odpowiednikiem są trasy i kontrolery. Formularz wysyła żądanie do endpointu Laravela, a nie do funkcji serwerowej Reacta,
API resume i częściowe prerenderowanie — to narzędzia dla frameworków budujących własną warstwę renderowania. Inertia ma własne SSR.

To nie jest brak — to inny podział odpowiedzialności, w którym logika biznesowa nie migruje do warstwy widoku. Dla zespołu, który pisze w PHP i chce tam zostać, jest to zaleta, nie kompromis.

Co działa u nas w całości

Kompilator — to zwykła wtyczka etapu budowania, więc działa w Vite tak samo jak wszędzie. Włącza się przez konfigurację wtyczki Reacta:

// vite.config.js
import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [
    laravel({
      input: 'resources/js/app.jsx',
      ssr: 'resources/js/ssr.jsx',
      refresh: true,
    }),
    react({
      babel: {
        plugins: [['babel-plugin-react-compiler', {}]],
      },
    }),
  ],
});

A reguły lintowania — przez preset wtyczki hooków:

// eslint.config.js
import reactHooks from 'eslint-plugin-react-hooks';

export default [
  reactHooks.configs['recommended-latest'],
  // ...pozostała konfiguracja
];

Kolejność wdrożenia w istniejącym projekcie ma znaczenie: najpierw preset lintera i naprawa tego, co pokaże, potem włączenie kompilatora, potem usunięcie ręcznych useMemo i useCallback — i to ostatnie stopniowo, a nie jednym commitem, bo każde takie usunięcie jest zmianą zachowania, którą trzeba obejrzeć.

useEffectEvent jest u nas przydatny natychmiast. Klasyczny przypadek w aplikacji na Inertii: efekt nasłuchujący zdarzenia, który wewnątrz potrzebuje aktualnych propsów strony, ale nie ma się przepisywać przy każdej nawigacji.

<Activity> rozwiązuje problem, który w panelach administracyjnych wraca regularnie: zakładka z filtrami i tabelą, do której użytkownik wraca i chce zastać to, co zostawił. Dotąd wymagało to wynoszenia stanu wyżej albo do adresu URL.

Ślady wydajności w DevTools działają niezależnie od tego, skąd przychodzą dane. Przy tabelach na kilka tysięcy wierszy — co w panelach zdarza się częściej, niż powinno — to jest pierwsze narzędzie, po które warto sięgnąć.

Na co uważać

Aktualizacja Reacta jest zadaniem bezpieczeństwa. Trzy podatności w Server Components z grudnia 2025, w tym jedna dająca nieuwierzytelnione zdalne wykonanie kodu, ustawiają poprzeczkę. Nawet jeśli nie używamy RSC, warto wiedzieć, czym się nie jest dotkniętym, zamiast to zakładać,
Trzy równoległe linie wsparcia (19.0.x, 19.1.x, 19.2.x) oznaczają, że poprawka przychodzi na naszą linię — sprawdź, na której siedzisz, zanim uznasz, że aktualizacja wymaga skoku na najnowszy minor,
Kompilator wymaga poprawnego kodu. Mutacje propsów, warunkowe hooki, ustawianie stanu w efekcie — wszystko to jest łamaniem Reguł Reacta i wszystko to występuje w kodzie, który dotąd „działał". Lint pokaże skalę, zanim podejmiesz decyzję,
Usuń eslint-plugin-react-compiler, jeśli jest w projekcie — reguły są teraz w eslint-plugin-react-hooks,
useId zmienił format w 19.2. Jeśli cokolwiek w kodzie albo w testach zależy od kształtu tych identyfikatorów, przestanie działać,
Poradniki starsze niż rok są mylące. Nie tylko przez Create React App: całe rozdziały o ręcznej memoizacji stały się opisem problemu, którego kompilator już nie ma,
React Foundation to zmiana zarządzania, nie licencji. Nic nie trzeba robić, żaden warunek korzystania się nie zmienia — warto tylko wiedzieć, komu projekt dziś podlega,
Nowe repozytorium to react/react. Stare odnośniki działają przez przekierowanie, ale skrypty odpytujące API GitHuba o facebook/react dostaną odpowiedź „Moved Permanently" — i to jest realny sposób, w jaki ta zmiana potrafi zepsuć czyjś pipeline.

Podsumowanie

React w 2026 roku jest projektem w innym miejscu niż dwa lata temu — i to w trzech niezależnych wymiarach naraz. Co z tego wynika:

Projekt jest pod fundacją. React Foundation ruszyła 24 lutego 2026 pod skrzydłami Linux Foundation, z projektami React, React Native i JSX przekazanymi przez Meta. Licencja pozostaje MIT, zmienia się zarządzanie — a to zdejmuje ryzyko, które w 2017 roku było realne,
Repozytorium to teraz react/react — sprawdź, czy nic w Twoich narzędziach nie odpytuje starego adresu,
Aktualna linia to 19.2, najnowsze wydanie 19.2.8 z 21 lipca 2026, a łatki wychodzą równolegle na trzy linie minor,
Włącz React Compiler — jest stabilny od października 2025 i zdejmuje z zespołu całą kategorię pracy. W stacku Inertia plus Vite to kilka linii w konfiguracji,
Najpierw lint, potem kompilator. Preset recommended-latest z eslint-plugin-react-hooks pokaże, ile kodu łamie Reguły Reacta,
Usuwaj ręczną memoizację stopniowo, nie jednym commitem,
Sięgnij po useEffectEvent wszędzie tam, gdzie dotąd kłamaliśmy w tablicy zależności, i po <Activity> do zakładek, które mają pamiętać swój stan,
Traktuj aktualizacje Reacta jak aktualizacje bezpieczeństwa, bo od grudnia 2025 wiemy, że nimi bywają,
Nadrób nowości 19.0 — ref jako props zamiast forwardRef, funkcje czyszczące referencji, use(), <Context> jako dostawca i API wstępnego wczytywania zasobów,
Nie mieszaj akcji formularzy Reacta z useForm Inertii ani metadanych dokumentu z komponentem <Head> — oba mechanizmy się dublują i dają dwa źródła prawdy,
Przed skokiem na 19 przejdź przez 18.3.1, żeby zobaczyć ostrzeżenia o wycofywanych API. Pamiętaj, że propTypes przestają działać w milczeniu,
Nie potrzebujesz Server Components, żeby być na bieżąco. W stacku z Laravelem rolę warstwy serwerowej pełni PHP i jest to świadomy podział, nie zaległość.

Licencja: React jest rozpowszechniany na licencji MIT — permisywnej, bez copyleftu, bez warunków przy komercyjnym użyciu poza zachowaniem noty o prawach autorskich. Warto jednak znać kontekst historyczny, bo to jedna z niewielu historii licencyjnych w świecie open source, która realnie wpłynęła na decyzje technologiczne w firmach. React był początkowo licencjonowany na BSD z osobną klauzulą patentową, którą Apache Software Foundation uznała w 2017 roku za niedopuszczalną dla projektów w swoim ekosystemie. Facebook przelicencjonował wtedy React na MIT, ale przez kilka tygodni w wielu zespołach na poważnie rozważano migrację na Vue. Przekazanie projektu React Foundation w lutym 2026 domyka tę sprawę na poziomie ustrojowym: warunków korzystania nie może już jednostronnie zmienić żadna firma, bo prawa do projektu i znaków towarowych należą do fundacji z formalną strukturą zarządzania. Dla firmy budującej produkt na dziesięć lat to jest różnica między licencją, która jest permisywna, i licencją, która pozostanie permisywna.