W wielu projektach Laravel przychodzi moment, gdy Blade przestaje skalować: rosnący interfejs potrzebuje reaktywności, optymistycznych aktualizacji i komponentów wielokrotnego użytku, których partiale Blade i szuflada z jQuery już nie udźwigną. Dobra wiadomość — nie przepisujesz aplikacji. Inertia.js powstała dokładnie do takiej migracji: ten sam backend Laravel, te same trasy, ta sama autoryzacja, interfejs React wprowadzany modułami.
- ## Zasada migracji: jeden moduł na raz
Wielki rewrite to sposób, w jaki umierają projekty. Migracja na Inertię działa jak remont zamieszkanego domu — pokój po pokoju, reszta ciągle działa:
- Zainstaluj Inertię w istniejącej aplikacji (trzy pakiety Composer/npm, jeden middleware).
- Zbuduj powłokę React — stały layout (nawigacja, menu użytkownika) wspólny dla przyszłych stron Inertia.
- Wybierz pierwszy moduł o najlepszym stosunku wartości do ryzyka: zwykle ekran, na który narzekają użytkownicy, a nie najbardziej krytyczny.
- Przekonwertuj metody kontrolera tego modułu z
view()naInertia::render(). - Przenieś markup Blade do komponentów React — najpierw struktura, potem zachowanie.
- Powtarzaj. Trasy Blade mogą żyć jeszcze miesiącami.
Czego faktycznie dotyka migracja
| Warstwa | Co się zmienia |
|---|---|
| Trasy | Nic — te same adresy i nazwy |
| Kontrolery | return view(...) staje się Inertia::render(...) z propsami |
| Modele, polityki, walidacja | Nic |
| Widoki Blade | Zastępowane per moduł komponentami React |
| JavaScript | Stare skrypty umierają razem z widokiem, do którego należały |
| Autoryzacja | Nic — sesje, middleware i guardy bez zmian |
W tym tkwi cały trik podejścia Inertii: kontrakt backendu to sam Laravel. Nie ma API do zaprojektowania ani warstwy tokenów do dodania — uzasadnienie znajdziesz w Inertia.js z Laravel i React — SPA bez osobnego API.
Krok po kroku
Instalacja i szkielet
composer require inertiajs/inertia-laravel
npm install @inertiajs/react react react-dom
php artisan inertia:middleware
Metoda kontrolera przed i po
// przed
public function index(Request $request)
{
return view('orders.index', [
'orders' => Order::paginate(25),
'filters' => $request->only(['status', 'search']),
]);
}
// po — te same dane, strona React zamiast widoku Blade
public function index(Request $request)
{
return Inertia::render('Orders/Index', [
'orders' => OrderResource::collection(Order::paginate(25)),
'filters' => $request->only(['status', 'search']),
]);
}
Widok Blade zostaw w repozytorium do odbioru modułu — cofnięcie trasy to jedna linia. W okresie dwóch stacków linki między zmigrowanymi i niezmigrowanymi modułami działają jak zwykłe przejścia; użytkownik nie widzi szwu.
Pułapki, które zatrzymują migracje
Uwaga: Nie konwertuj całej warstwy danych na API resources w jednym przejściu. Propsy Inertii mogą serializować modele Eloquent wprost; resources wprowadzaj tylko tam, gdzie kształt payloadu ma znaczenie — zwykle tabele i formularze.
- Rozjazd designu. Gdy Blade i React żyją równolegle, oba potrzebują tych samych tokenów designu. Wyciągnij system designu do klas Tailwind wspólnych dla obu stacków przed startem.
- Najpierw formularze, potem widgety. Formularze noszą wartość biznesową; wykresy i dashboardy mogą poczekać. A formularze w Inertii mają własne wzorce, które warto poznać wcześnie.
- Brak testów na szwie. Trzymaj testy feature Laravela na tych samych adresach — łapią regresje niezależnie od tego, czy trasa renderuje Blade, czy React.
- Ekrany logowania na start. Kusi, bo proste — ale niosą najwięcej ryzyka. Przenieś je w środku harmonogramu, nie na początku.
Co zostaje na koniec
Po ostatnim module codebase to SPA w jednym repozytorium: routing i sesje Laravela, interfejs React, jeden deploy. Zespoły, które chcą siatki bezpieczeństwa, mogą zostawić Blade dla stron wewnętrznych na zawsze — wielu naszych klientów ma React w produkcie i Blade na stronach prawnych i marketingowych, które zmieniają się raz w roku.
Jeśli wolisz oddać migrację zespołowi, który robił to już wielokrotnie — zobacz tworzenie aplikacji Laravel; zakres migracji wyceniamy per moduł po krótkim audycie.
FAQ
Czy migrację można robić etapami?
Tak — Inertia i Blade współistnieją w jednej aplikacji. Trasy renderują jedno albo drugie niezależnie, więc aplikacja działa po każdym kroku.
Ile zmienia się w backendzie?
Niewiele. Kontrolery, modele, walidacja i polityki zostają; view() zmienia się w Inertia::render() z propsami.
Ile to trwa?
Zależy od liczby ekranów, nie od rozmiaru kodu: moduł 5–10 ekranów to zwykle 2 000–8 000 zł netto i 1–3 tygodnie, razem z komponentami React i testami.
👉 Planujesz migrację z Blade na Inertię? Zobacz tworzenie aplikacji Laravel albo programista Laravel na zlecenie — przygotujemy plan migracji moduł po module.
📖 Czytaj dalej: Inertia.js z Laravel i React, formularze i walidacja w Inertia.js i Inertia.js czy Livewire.