Week 29: Laravel + SPA Integration with Inertia.js

1. The Problem Inertia Solves

Week 15's REST API approach means building and maintaining two separate concerns: a versioned API surface (routes, Resources, auth tokens) and a frontend that consumes it, each with its own routing, its own auth handling, its own request/response contracts to keep in sync.

Inertia.js takes a different position: keep Laravel's routing, controllers, session-based auth and validation exactly as built in Weeks 9-14 — but instead of returning a Blade view, a controller returns the name of a Vue or React component plus the data it needs. Inertia handles turning that into a real client-side page render, with no API layer in between at all.

Blade (Week 9):        Controller → Blade view → full page reload on every navigation
REST + separate app:   Controller → JSON → a fully separate frontend app, own routing
Inertia (this week):   Controller → Vue/React component + data → SPA-like nav, one Laravel app

Inertia is the right fit specifically when a team wants a modern, SPA-feeling frontend without paying the cost of a second, fully independent application to build, deploy and keep in sync — a real trade-off against Week 15's approach, not a strict upgrade.

2. Setup

composer require inertiajs/inertia-laravel
php artisan inertia:middleware

npm install @inertiajs/vue3 vue

<?php

->withMiddleware(function ($middleware) {
    $middleware->web(append: [
        \App\Http\Middleware\HandleInertiaRequests::class,
    ]);
})

This registers Inertia's middleware alongside every other web middleware from Week 14 — auth, CSRF protection, and session handling all continue to work exactly as before. Inertia adds a rendering layer on top; it doesn't replace the request pipeline underneath.

3. Rendering Pages

A controller returns Inertia::render() instead of view() — same routing and controller structure from Week 10, different return value:

<?php

use Inertia\Inertia;

class TaskController extends Controller
{
    public function index()
    {
        return Inertia::render('Tasks/Index', [
            'tasks' => auth()->user()->tasks()->with('tags')->get(), // eager-loaded, per Week 12
        ]);
    }
}

<script setup>
defineProps({ tasks: Array });
</script>

<template>
  <div>
    <h1>Tasks</h1>
    <ul>
      <li v-for="task in tasks" :key="task.id">
        {{ task.title }}
        <span v-if="task.is_done">(done)</span>
      </li>
    </ul>
  </div>
</template>

'Tasks/Index' resolves to resources/js/Pages/Tasks/Index.vue by convention. Navigation between Inertia pages happens client-side, without a full page reload — but every navigation still goes through a real Laravel route and controller, unlike a traditional SPA's client-only routing.

4. Forms & Validation

This is where Inertia's approach diverges most visibly from Week 15's API pattern — validation errors from a Form Request flow straight through to the frontend, with no manual JSON error-handling required:

<script setup>
import { useForm } from '@inertiajs/vue3';

const form = useForm({ title: '', priority: 'medium' });

function submit() {
  form.post('/tasks'); // hits the exact same store() route from Week 10
}
</script>

<template>
  <form @submit.prevent="submit">
    <input v-model="form.title">
    <div v-if="form.errors.title">{{ form.errors.title }}</div>
    <button :disabled="form.processing">Create</button>
  </form>
</template>

<?php

public function store(StoreTaskRequest $request)
{
    auth()->user()->tasks()->create($request->validated());

    return redirect()->route('tasks.index');
}

When StoreTaskRequest's validation fails, Inertia automatically catches the redirect-with-errors response (Week 10's exact mechanism) and populates form.errors on the client — the same server-side validation rules from Week 10, now surfacing directly in the Vue component with zero extra client-side validation logic duplicated.

5. Shared Data

Data every page needs — the logged-in user, flash messages — is declared once in middleware rather than passed manually from every controller:

<?php

public function share(Request $request): array
{
    return [
        ...parent::share($request),
        'auth' => [
            'user' => $request->user(),
        ],
        'flash' => [
            'success' => fn () => $request->session()->get('success'), // Week 10's flash data
        ],
    ];
}

Every Inertia page component now has $page.props.auth.user and $page.props.flash.success available automatically — the flash-message pattern from Week 5 and Week 10, now flowing through to a JavaScript frontend without any per-page plumbing.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.