Inertia.js v3.1: Rescued Deferred Props and the Axios-Free Stack

Host: Hey everyone, welcome back to Allur, your go-to spot for everything happening in the world of PHP, Laravel, and modern web development. I’m your host, Alex Chan. Host: Joining me today is Mark Sterling. Mark is a Senior Lead Developer at NorthStack, where they build some of the most complex Laravel-Inertia apps I’ve ever seen. Mark, it is so great to have you on Allur. Guest: Thanks, Alex! It’s great to be here. Honestly, I’ve been waiting for this specific update for a while, so I’m stoked to chat about it. Host: I can tell! So, let’s jump right in. Inertia v3.1—the community is calling this a "pivot point." In your eyes, why is this release such a big deal compared to, say, the jump from version 1 to 2? Guest: Yeah, that’s a great way to put it. You know, version 2.0 gave us "Deferred Props," which was huge. It meant we could load a page and let the slow stuff—like a heavy report or a third-party API call—load in the background. But the problem was stability. If that background call failed, the whole UI could just… well, it could get messy. Host: "Rescued Deferred Props." I love that name—it sounds like a superhero team or something. Can you explain for the listeners what exactly is being "rescued" here? Guest: Haha, it kind of is a superhero for your UI! So, okay, imagine you have a dashboard. You’ve got your user stats, a list of recent orders, and then a little widget that shows, I don't know, live currency rates from an external service. In v2.0, you’d "defer" that currency widget so the rest of the page loads instantly. But if that currency service timed out or threw a 500 error during a refresh, the user might see a blank spot or, worse, a crash. Host: Oh, interesting! So it’s like a "stale-while-revalidate" approach, but specifically for when things go south? Guest: Exactly. It’s about "graceful degradation." Instead of the "white screen of death," the user just sees slightly older data for that one specific piece while the rest of the app stays totally interactive. For enterprise apps, where uptime and perceived stability are everything, this is a massive win. Actually, we had a project last month where a slow database query was causing intermittent UI flickers on reloads. If we’d had v3.1 then, the users wouldn't have even noticed the blip. Host: That’s such a relief for developers. I mean, we’ve all been there where one slow API call ruins the whole user experience. But let’s talk about the other elephant in the room: the "Axios-Free Stack." This one surprised me. Inertia has used Axios since day one, right? Guest: Since day one. It was the industry standard. But, if you look at how the web has evolved, native Fetch and XHR capabilities in browsers are actually really good now. By removing Axios, Inertia is basically saying, "We don't need this extra weight anymore." Host: Is the bundle size difference that noticeable? Guest: It’s significant! It’s not just the kilobytes of the library itself, but it’s the dependency tree. When you strip that out, your Time to Interactive—or TTI—gets a nice little boost. But more importantly, Inertia now uses its own internal XHR client. This means the framework has 100% control over how requests are intercepted and handled. It’s "tuned" specifically for the Inertia protocol. Host: Okay, but I’m thinking about all the developers out there—myself included—who have built their whole auth systems or header management using Axios interceptors. Does this mean we have to rewrite everything? Guest: (Laughs) Well, the short answer is "yes," but the long answer is "it’s easier than you think." You can't use `axios.interceptors` anymore because, well, Axios isn't there. Instead, you move that logic to Inertia’s native event hooks. So, you’d use `router.on('before', ...)` or `router.on('error', ...)`. Host: Right, it’s more unified. It’s not "Inertia + this other library," it’s just… Inertia. You mentioned it signals that the framework is maturing. Where do you see this going next? Is this the end of the "glue" era? Guest: I think so. Inertia is becoming a "robust foundation." We’re seeing it move toward a "zero-config" future. They’re handling the plumbing—the headers, the status codes, the state preservation—so we can just focus on building the product. Host: It’s such an exciting time to be in the Laravel ecosystem. It feels like every few months, the "floor" for what a "good" app looks like just gets raised. Guest: Totally. And the best part is, even with these big changes, the upgrade path in Laravel is usually pretty smooth. The Inertia team is really good about documentation. Host: Mark, this has been so enlightening. Before we wrap up, for someone listening who’s looking to migrate their app to v3.1 this weekend, what’s your one "pro-tip"? Guest: Ooh, good question. I’d say: start by auditing your Axios interceptors. Map them out on a piece of paper first. See what’s adding headers, what’s handling 401 errors, and then look at the new Inertia `router.on` documentation. Once you get that bridge crossed, the rest of the upgrade is honestly a breeze. And definitely play around with `Inertia::defer` in your controllers to see those rescued props in action—it’s actually pretty satisfying to watch a page *not* break when you force an error. Host: (Laughs) Breaking things on purpose to see them stay fixed—the true developer way! Mark, thank you so much for joining us on Allur. Guest: My pleasure, Alex! Thanks for having me. Host: What a great conversation. It’s fascinating to see Inertia.js move toward this self-reliant, Axios-free future. The takeaway for me today is that stability doesn’t just mean "it works when everything goes right"—it means "it works even when things go wrong." Those "Rescued Deferred Props" are a game-changer for anyone building complex dashboards or data-heavy apps.