All right, next up I want to move on to upgrades, but first let me show you where we currently are. So behind the scenes, as we discussed, I continued working on each section one at a time. And yeah, compared to back-end code, it's a little bit slower of a process. It's a lot more back and forth from my experiences. But I think this is getting to a nearly pretty good state, nearly pretty good high praise. But yeah, I think it looks good. So I can

good state, nearly pretty good high praise. But yeah, I think it looks good. So I can now create assignments. Maybe let's create assignments for them. How about customizing filament? That's all working. They get their invitations. I can remove people. There's a lot to it, but it's looking good, I think. Okay, so now imagine we need to upgrade this in some way. And here's the example I have for you. At the time of this recording, inertia.js,

in some way. And here's the example I have for you. At the time of this recording, inertia.js, which you can think of sort of like the glue that connects Laravel to our front end framework called View. It just facilitates things, makes it easier. It allows us to leverage the best of both worlds, I would say. Anyways, as I record this, they have now released the beta for version three. And let's imagine I want to pull this in and also take advantage of

for version three. And let's imagine I want to pull this in and also take advantage of some of its new features. What does the workflow look like for that? Well, let 's see. If we scroll down, again, this isn't going to be an inertia three tutorial, but you can get the gist. It includes a new vid plugin, a composable, effectively for performing general HTTP requests as you see here that are outside of the inertia lifecycle. It has support for optimistic updates,

as you see here that are outside of the inertia lifecycle. It has support for optimistic updates, which I think we can use here. Update the UI immediately without waiting for the server to respond. So we are optimistically applying these changes. And then if anything goes wrong, it will update. That leads to a better feeling or a better performing experience. Well said, Jeffrey. Anyway, simplified SSR exception handling. All right, here's the point . I want

Jeffrey. Anyway, simplified SSR exception handling. All right, here's the point . I want to pull this in and implement some of these updates into our dashboard, but I want to leverage AI every step of the way. So here's what we're going to do. The first step is, at the moment, this is brand new AI probably doesn't know anything about it, doesn't have anything to pull from. So I'm going to copy this page here. Okay, so I have a fresh cloud

anything to pull from. So I'm going to copy this page here. Okay, so I have a fresh cloud instance. And yeah, let's just say inertia V three beta we've recently released . I want you to review the documentation and make a plan. Notice I do our plan mode turned on for how we can best leverage its new features specifically as it relates to the team dashboard just for now. Okay, next I'm going to paste in all of that documentation. All right, and

just for now. Okay, next I'm going to paste in all of that documentation. All right, and let's give it a go. Okay, that's done. So let's take a look at the plan. First step, chain once unstable deferred props. So when users switch between members view all deferred props refetch, including the sidebar data that doesn't depend on the selected member. Okay, so here's what that means. All right, so for example, if I click on a member, now I can still see

what that means. All right, so for example, if I click on a member, now I can still see the dashboard, but it's all scoped and limited to her. So it looks like she joined in February, I can see only her activity, only her assignments as you see here. But then I could switch to somebody else and we're going to do the same thing. All right, so what the plan is is suggesting is, well, you're still fetching all of these deferred props for each load, even though

is, well, you're still fetching all of these deferred props for each load, even though you don't need to, it's the exact same thing. So it would be cool if we could only use each of those once, which is one of the new things within inertia three. All right, here we go. So some data rarely changes, rather than including this data in every response, you can use once props so you basically reuse that data for the next page load. So all we have to do is

props so you basically reuse that data for the next page load. So all we have to do is switch over to inertia. Once after the client has received this prop, subsequent request will skip resolving the callback and exclude it from the response. Very useful and we should definitely use that. It's ideal, actually, in this case, where I switch members . And now, yeah, like, none of this needs to change. None of the recently released series doesn't

now, yeah, like, none of this needs to change. None of the recently released series doesn't need to change. So that's a great use case. Cool. We're going to do that. So it 's recommending in my controller that it switches over. So notice we are currently using inertia defer, but after we're going to append the once method. Cool. Next step, use reloading slot prop on deferred components. Okay. So keep in mind as I do this, inertia V three is brand new

deferred components. Okay. So keep in mind as I do this, inertia V three is brand new to me. I barely understand what's new. That's why this is a fun video. So in inertia three, the deferred component exposes a reloading Boolean during partial reloads. Instead of flashing skeletons when data refreshes, we keep existing content visible with a subtle loading indicator. Okay. So yeah, this is what we have currently. I use the deferred component.

loading indicator. Okay. So yeah, this is what we have currently. I use the deferred component. This is all new in inertia two, by the way, you can specify what should be displayed while all that data is loading in, usually like a spinner or a dummy skeleton or something like that. Instead, they want us to show this right here. So we wrap everything within a div. And we make the opacity 50% if it is currently reloading. And we accept that here

div. And we make the opacity 50% if it is currently reloading. And we accept that here scoped. Okay, let me learn a little more about this. A new reloading swap prop is available across all adapters, allowing you to show a loading indicator during partial reloads, while keeping the existing content visible. Yeah, I'm just not entirely sure what that means. Like I thought, I thought that's what this is already doing. This is the fallback

means. Like I thought, I thought that's what this is already doing. This is the fallback while it's reloading. So I need to learn a little more about that. I assume it 's related to when you're exclusively doing partial reloads. Nonetheless, let's see. So it 's recommending we, okay, so what, okay, when it's reloading the data, it just fades it out a little bit to make it clear like, hey, something's happening here. Don't interact with me. Okay, we'll try

to make it clear like, hey, something's happening here. Don't interact with me. Okay, we'll try that out. Next number three, replace axios in stats section with use HTTP. Yes, absolutely. So before we were directly using axios. But now in inertia three, there's an HTTP composable that does not use axios, I don't think. So maybe I can migrate to that and then retire our usage of axios entirely just to save on a little space. I think that would be cool.

our usage of axios entirely just to save on a little space. I think that would be cool. Okay, so yeah, instead of axios.get, I can now leverage the built-in composable . Great, we're going to do that. Next, you'll see the exact same thing here. So I already had my own HTTP service. And in fact, right up here, like we should have been using that. But nonetheless, my service did almost the same as what this new HTTP composable does. So I think we can

my service did almost the same as what this new HTTP composable does. So I think we can migrate to that entirely. Next, replace, okay, blah, blah, blah. What else do we got? Nested deferred props. So these three supports deferred props inside closures and nested arrays. We could group sidebar data under a sidebar key for cleaner organization and dot notation partial reloads. That's kind of cool. So now I can say, here's our sidebar. Here's the

partial reloads. That's kind of cool. So now I can say, here's our sidebar. Here's the leaderboard. Here's the recently released. And then I can interact with it through dot notation. And then I wonder, can I also just do inertia defer at the top level? Maybe, maybe not. Recommendation skipped this for now. Okay, it adds refactoring churn for minimal benefit since the grouping already works fine. Okay, let's just ignore that for now. What

benefit since the grouping already works fine. Okay, let's just ignore that for now. What else do we got? Future considerations, instant visits. Yeah, I'm kind of curious about instant visits. This allows you to instantly load a page before the data has been fet ched. And as long as you can handle the display when that data is not available, you can have an instant page load. And then you fetch the data behind the scenes. So you want to navigate

instant page load. And then you fetch the data behind the scenes. So you want to navigate to a new page without waiting for the server to respond, instant visits allow inertia to do this. So yeah, this is kind of a sharp knife, I would say. I'd have to be a little careful about switching to that. The page swaps instantly while the server loads the member specific data, this adds complexity. It's worth exploring in the future. Okay.

member specific data, this adds complexity. It's worth exploring in the future. Okay. And then optimistic updates for member removal. Yeah, this is a this exactly the use case. I had my mind actually. Okay, so let's say we are removing a member, let's switch back. Something like this, if you think about what happens if I remove Emily, sure about that, it submits to the server, and then it updates the page. If you think about it, we can optimistically

it submits to the server, and then it updates the page. If you think about it, we can optimistically assume this is all going to work just fine. So why do we have to wait for that entire action to complete? Can't we just optimistically update the page to reflect that? And the answer is, yes. So let's see how optimistic updates work. I'm sure it allows you to update the UI immediately without waiting for the server to respond. Yep, yep. So we just say router

UI immediately without waiting for the server to respond. Yep, yep. So we just say router and then do an optimistic update. This callback receives the current page props and should return a partial update to apply immediately. Yeah, so it's your way of saying like, okay, we're going to update the page using this data that I've updated and then it will make the request and then swap out the props once it's done. But you get again, just much, a much

request and then swap out the props once it's done. But you get again, just much, a much better performance in terms of how it feels. The optimistic update is applied immediately to the current pages props. So your component rerenders with the new values before the request is sent. Okay, so what I'm going to do is I want to do that one here. So let's say right here, plan looks good, but also implement, and then I'll just paste that in as part of

here, plan looks good, but also implement, and then I'll just paste that in as part of this refactor. Alright, that's done. So let's take a look. All 190 tests pass. I did temporarily have to disable Laravel Nova just because it hasn't been updated yet. But that 's just short term. We upgraded inertia to V three. We republish the inertia config. And here are the various files that it updated. So it is now using that once API, we added support

are the various files that it updated. So it is now using that once API, we added support for the reloading prop. We're now using the use HTTP composable. And we're also making use of optimistic updating for instant member removal with auto rollback on failure. Cool. Let's try it on the browser. I'm excited. All right. So here we are. The page is still working, which is always a good sign. Let's try a couple of things out. Like let's remove

working, which is always a good sign. Let's try a couple of things out. Like let's remove Marcus, but then close this out while it's still working. And it's very quick. I'd have to slow this down. But the page did update right away to reflect the fact that Marcus was gone. And then behind the scenes, it makes the update and then it merges the updated props in. Cool. Optimistic reloading. Next, let's see if I can illustrate the once usage.

props in. Cool. Optimistic reloading. Next, let's see if I can illustrate the once usage. So yeah, let's try this. Let's open up the network tab. And I'm going to give it a refresh. And let's see, it's going to take a look at a couple of things here. Okay. So here, if I take a look at what was requested, you can see this is actually the partial reload. So this is the deferred. It's getting the activity feed and the assignments, but then

So this is the deferred. It's getting the activity feed and the assignments, but then we have another one. If I scroll down here, this is getting the leaderboard and the recently released. But further, if I go into preview, take a look. We have this once props section. So now we're keeping track of data that we've already load that can be reused when we visit another page. So if I were to, for example, go to Tom's page. But notice once again, it

another page. So if I were to, for example, go to Tom's page. But notice once again, it doesn't have to refetch the leaderboard and the plans. It can just reuse all of that stuff, which is really cool. So here, we're making use of regular props, deferred props, and then also once props, which is kind of cool. Everything still works. But again, this is all just to allow for a speedier page load. And I think that does make a big difference.

all just to allow for a speedier page load. And I think that does make a big difference. Okay. So what's the point of all of this? It's to illustrate that even if you don't mentally have time to learn what's new and every framework update or package release with AI, it's fine. You can just tell AI, hey, here's a new thing. I want you to consume it. I want you to consider how we can best make use of these features practically within

it. I want you to consider how we can best make use of these features practically within the code base and then make a plan and let me know how we can make this upgrade right away, right? It'll make the plan. And as part of that plan, it's going to teach you along the way about some of these new features, which also I think is very, very cool stuff. Don't skip over the learning part. And that mostly does it. So the workflow is dramatically different

skip over the learning part. And that mostly does it. So the workflow is dramatically different than what I might have done five years ago. A lot quicker, but there's no question about it. It looks nothing like what I was doing in 2020 even. So it's fun times. If you have any tips for me, be sure to let me know. Otherwise, I'll see you next time.