ix
ix

informatix

EN version Porozmawiajmy o projekcie
Strona główna / Blog / Migracja widoków Blade na Inertia.js — krok po kroku [2026]
• 4 min czytania •

Migracja widoków Blade na Inertia.js — krok po kroku [2026]

Jak przenieść istniejącą aplikację Laravel z Blade na Inertia.js + React bez przepisywania: zakres modułami, okres dwóch stacków, wspólny layout, autoryzacja i błędy, które zatrzymują migracje.

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:

  1. Zainstaluj Inertię w istniejącej aplikacji (trzy pakiety Composer/npm, jeden middleware).
  2. Zbuduj powłokę React — stały layout (nawigacja, menu użytkownika) wspólny dla przyszłych stron Inertia.
  3. Wybierz pierwszy moduł o najlepszym stosunku wartości do ryzyka: zwykle ekran, na który narzekają użytkownicy, a nie najbardziej krytyczny.
  4. Przekonwertuj metody kontrolera tego modułu z view() na Inertia::render().
  5. Przenieś markup Blade do komponentów React — najpierw struktura, potem zachowanie.
  6. 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.

Powiązane wpisy

20.10.2026

Formularze w Inertia.js — useForm i walidacja [2026]

Kompletny zestaw narzędzi do formularzy w Inertia.js: hook useForm, walidacja Laravela mapowana na pola, obsługa błędów, upload plików, progress i ostrzeżenia o niezapisanych zmianach — z kodem.

Czytaj dalej