Inertia.js Reload Props After Post Requests: Decoding the Redirect Mystery

As a senior developer working with modern full-stack frameworks, I often encounter subtle yet frustrating issues when mixing traditional server-side redirects with Single Page Application (SPA) paradigms like Inertia.js. The scenario you've described—where an Inertia post leads to a Laravel redirect, followed by an Inertia::render returning data—is a classic point of confusion regarding how the client-side state is updated.

This post will dissect why your page might not be reloading or rerendering as expected after a successful form submission and guide you toward the robust solution using Inertia's intended patterns.

Understanding the Flow: Where Things Go Wrong

Let’s first trace the journey of your request, which perfectly illustrates the conflict between standard HTTP redirects and Inertia's data-driven approach.

1. Initial Action: Inertia.post("/ban", ban) is sent to the server.
2. Server Processing: Your Laravel controller executes the logic (e.g., database update).
3. The Redirect: The controller executes return Redirect::route("speler", [$steam])->with("success", "Ban doorgevoerd!");. This generates a standard HTTP 302 redirect response.
4. Inertia Rendering: The final step is returning Inertia::render(...) with the new data.

The problem often lies in how the browser interprets that final redirect in conjunction with the Inertia response. A standard server-side redirect tells the browser to fetch a completely new page, which can sometimes bypass or confuse Inertia's client-side state management if not handled carefully. The framework expects an Inertia response (a full HTML payload containing Inertia data) rather than purely navigational redirects for state synchronization.

The Core Issue: Redirect vs. Response

Inertia thrives when the server sends back a fully rendered Inertia response. When you use Redirect::route(), you are telling the browser to navigate away, which is fundamentally different from sending an Inertia payload that tells the client what to render next. If the subsequent route handler (PageLoader) correctly renders an Inertia view, the component state should refresh automatically, provided the data flow is smooth.

The lack of re-render usually