Inertia.JS reload props after post request

# 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