Now with the NERSH's router and its link component, we can specify how we want data to reload as well. So we can limit the reload functionality of an action down to

just a specific set of keys for our controller to then return back. So within our login page, let's start by defining some props that we'll expect from our servers.

We can define props, provide in an object. First, we'll have a render count of type number, then we'll have a refresh count one. So we're going to have two of these,

we'll have a refresh count two, and then we'll also have a lazy count as well. Let's also get some of our contents off of the edge of the page by wrapping

our link component in an extra div with a class flex, flex, call, justify, center, space, y, six, width,

full, small, width, and we'll set that to 350 pixels, and then mx auto to center it all up. Take that end div and plop it down at the end of our template,

and then indent everything. Inside of that new div that we just added, let's add a couple of buttons. So first, we'll have a button with an at click, which equals our router.

So we'll want to import that. So we'll jump up to our scripts and import router from at inertiajs-v3. Jump back down to our button now,

and we'll do router.reload to simply reload the page and all of its data. That'll pretty much just send out another get request for this page and then update all of its info.

The contents of this button will be render count, and then we'll go ahead and render out that render count. We'll have another button. For this one, we're going to want to use the link component.

So we'll specify that the click handler should be passed down and cascaded to the child, and then we can make use of our link, point the href to slash login,

and the text for this one will be refresh count one. Then we'll render out our refresh count one just like so, and out, link, there we go.

Then we can give this button here a copy and paste it two more times. Scroll down a little bit here. The second one will be our refresh count two,

and we'll update the count for that there as well to 0.2 refresh count two. Then this one is going to be our lazy count. So we'll render out our lazy count.

Now, we're going to leave all of our links pointing to slash login so that they pretty much just return us back to this page. At present, all three of these links,

including our button here with router.reload are going to behave the same. We're just going to reload our page. We can give this a save.

Let's jump into our routes and let's pass in these props here real quick. So I'm just going to go ahead and give this object a copy, jump into our routes. We added this to our login page, so we'll jump into our login,

and we can plop that right on in. Give it an indent, and now we need to replace our types with actual values. So that these values can increment with each request that we send,

we're going to store them outside of our route handler inside of our routes file. So just right up here at the top, let's do let render count equal zero,

let refresh count one equal zero, let refresh count two equal zero, and then let lazy count equal zero there as well.

Then let's jump down to our actual props, replace our types with those values. So we do plus plus render count to increment

our render count by one and then set the render count value. So on our initial render, render count should be one rather than zero,

and we'll do the exact same thing here for a refresh and lazy counts as well. So plus plus refresh count one, plus plus refresh count two,

and then plus plus lazy count. All right, we'll leave all of these as is, we're not quite done with them yet, but let's take a look and see what we have. So we'll jump back into our browser.

Let's head over to our login page because that's where we added this in, and just as expected, we can see all of our counts are at one because we're doing plus plus and then calling the value passing the props.

If I click on our render count, all of these jump to two because that's run yet again, click on any of these other buttons, they just all increment in the same piece.

Now it's time to make use of the superpower that the link component has that allows us to discern what information should actually update whenever we run through a route handler.

So we're going to leave our render count as is. This is just going to be a simple reload. For our refresh counts though, we'll have these only update specific properties,

and we can specify these using the only prop. We pass in an array with the keys that we want to include with this update.

So this will be our refresh count one because this is the prop that we're passing in from our routes that we want to update whenever we click on this button.

So our desire here is that whenever we click the refresh count one button, only our refresh count one actually increments, the others remain the same. That's our desired behavior.

Let's go and add that into our refresh count two here as well. So refresh count two, and inside of our view application,

our lazy count is going to be the exact same, only lazy count. Where this one is different is inside of our controller, but we'll leave it as is for right now just so that we can see the difference.

Again, we're not quite done with this yet, but let's take a look and see what the behavior is inside of our browser. Again, if we just do a simple refresh, all increment by one, same thing with our render count,

all are going to increment by one. If we click our refresh count one, you'll see that that one there only incremented or so it appears. If I click on refresh count two now,

you'll see that that jumped straight from seven up to nine. So although that property was not included with the updated information,

it was still updated whenever we clicked on our refresh count one. For example, if we click our refresh count one again, it incremented whenever we clicked on our refresh count two.

So rather than going to nine and incrementing by one, it's already at nine, it just hasn't updated on our client. So whenever we click on this again,

it's going to jump straight to 10 as you see there. The reason for this is because inside of our routes file, all of these increments are still executed

whenever we call our login route handler, and that's just native JavaScript execution. We're passing in an object, so all of these properties are going to be evaluated.

Hence, each one is going to increment by one regardless of what we specify on our client as the only prop that we want to update. Inertia is though however,

plucking out all of the extras and just passing in a refresh count one or refresh count two via the only. So if we jump back into their browser,

right-click this, inspect, jump into our console, and let's click on our refresh count two again, you'll see that jump from nine now to 11. Let's take a look at the response for this.

So you see for the props, we only get back that refresh count two. So it is omitting all of them there on our returned prop data,

but it is still running and executing on our server. If we didn't want it to run and execute on our server, we could instead of passing these values indirectly,

wrap them in a callback function. This will allow Inertia to defer its execution via the render method,

and now our increments will only be evaluated whenever we specifically want to update these props. So let's go ahead and give that a save.

We'll leave our lazy again as is for right now. Jump back into our browser. We saw everything just do a nice refresh there because we updated our route file holding our increment values.

So we're all back to one. I'm going to go ahead and collapse that down slightly. Same behavior if we click on our render count, everything's just going to increment by one because we're including the entire set of our data.

However, this time whenever we click on our refresh count one, you'll see that only our refresh count one incremented, which on the client side is the same behavior that we saw before.

But now if we click on our refresh count two, instead of jumping from two to four, it now has not incremented yet on our server.

So instead, it will jump from two to three because its value is now wrapped in that callback function. So it's not automatically going to be evaluated whenever that code runs.

Awesome. So now we have our refresh counts as expected, and these increments are only going to actually increment whenever we make a call specifically for them.

Lastly, what about this lazy count right there? Well, at present, it's going to behave the same as the others, but we haven't wrapped it yet inside of that callback function. So it has been incrementing this whole time.

So let's go ahead and jump back into our route definitions here. Whenever we're taking a look at our CTX inertia, so CTX inertia,

one of the items that we have available is this lazy method. This allows us to lazily resolve values only when they're specifically requested.

So if we add in this lazy here, provide in a callback, and then we'll end that lazy call right there.

Our lazy count will only ever increment by executing this callback whenever we specifically specify that we want to update and include our lazy count.

So if we give this a save here, all of our numbers just refresh back to zero because our server restarted our route file. Jump back into our browser, we can see it do a nice refresh there.

Everything's reset. You'll see that a value for our lazy count has been omitted altogether. It wasn't even included with the initial render because it wasn't specifically requested.

As we click on these other buttons, they're all going to increment by one. You see our render count increments everything except for our lazy count, because yet again, it has not been requested.

But if we click on our lazy count, now it's going to increment because we are specifically requesting it. So that's a cool feature that you can add in if there's

some minute information that you only need to include in very specific circumstances. You can just wrap it in that lazy call, and now anytime that you specifically request it,

it will be included, otherwise, it'll be omitted altogether, which is pretty cool.