And then if you are relying on these being synchronous in your code, you can go ahead and adjust them. So let's hop over and create a really basic example of this. It's really difficult to demonstrate this, so I'm going to do my best. OK, so let's head over to our web routes and let's go down to our dashboard once again. In here, we're going to go ahead and output the current date time, just so we can see some sort of changing value, change as we make requests.

So we're going to say Inertia and Lazy. Remember, we're working on v1 at the moment, so we don't have that optional method. This is now Lazy. And in here, what we're going to do is we're going to sleep for a specified amount of time from our request, which will send in the query string. So bear with me if this doesn't make sense. As we start to pull in the buttons to get this to work, it will start to make sense. So we're going to sleep for a specific delay from our request. So let's go ahead and make sure we pull that in from here.

And let's go ahead and bring this into scope within this closure, and then we're going to go ahead and return the current date and time to a date time string. OK, let's get this output on the page and make a request to update this value. So let's go over to our dashboard. Let's go and define our props here. And this is going to be that date time string. Let's pull that in and we'll go down here and dump this out in here. Now, at the moment, if we head over, we don't see anything because, of course, we've marked that as Lazy and we're going to need to make an initial request to pull this in.

So let's create out a reload function in here to reload this, and we'll pass in the delay here with a default of zero. And we'll just use router to reload this, our inertia router to reload this and make sure we import this. And what we're going to do is we're going to pass in to our data the delay here. So let's pass that delay and we can either do this or just this. And then we are only going to refresh that date time.

And then what we can do once this component is mounted, we can go and reload this with a delay of zero. So basically get that initial value when we refresh the page. What we can now do is we can create a button to show what's going to happen when we make a partial request and the difference between the synchronous and the asynchronous versions. So let's create out a button in here to reload this. And when we click on this, we're going to set a reload here with zero.

And let's say reload, let's just call this normal request and let's call this slow request. And we'll set the delay on this to something quite big, let's say three seconds. OK, great. So when we send a normal request down, that's just refreshing the prop with that route to reload. But when we send down a slow request, that's obviously going to take a delay of three seconds since we're passing that in the query string.

And that's going to take three seconds for that data and that prop to be reloaded. OK, so now we're working in Inertia V1. Let's make a slow request and then immediately hit this button to make a normal request or press slow request twice. It doesn't really matter. OK, so I'm going to press slow request and I'm going to press normal request. Now, notice what's happened is the previous request here was cancelled and then this one was immediately run.

So this is synchronous. We're running these in order of what we've clicked on them or sent the request over. But this one has been cancelled now. And then this data from this new request that we're making will have taken effect. So even though that this slow request is running, I click this, this data immediately updates. Now, let's go ahead and switch over everything that we've got here to Inertia V2 to see the difference.

So let's go back over and we'll do NPM install on Vue 3 next and we'll do a composer require on Inertia Laravel 2 dev. OK, so now that we've done that, let's go back over and rerun NPM run dev and let's take a look. OK, great. So now I'm going to hit slow request and normal request and you can see both of these are happening asynchronously. So I can press this as many times as I want and all of these will be queued up and run at the same time.

So it's really difficult to figure out a scenario where your data would rely on these synchronous versus synchronous requests between version 1 and 2. But hopefully that gives you a visual idea of how these are different between version 1 and 2. And you can adjust your code accordingly if you were relying on slow network requests or network requests to run next to each other. And more importantly on V1, any subsequent requests that the user makes to be cancelled.

I think that's the main thing here. If you were to click on a request and then click on another request, if you were expecting the previous request to get cancelled to adjust your data somehow or display new prop data, then you'll need to tweak your code to get this working. Probably pretty rare that you're going to come across this, but it's good to know the difference between V1 and V2 and how partial reloads work.