Right, do you want to see something pretty interesting? Come with me, check this out. So, I'm on the Post show page and we have our paginated comments that we created in the last episode. Now, I'm going to open the network panel here and I'm going to use the paginator to go to the last page of comments. So, as we'd expect, we hit this 170, which is obviously the post ID, and we're asking for the page of 1. Let's take a look at the preview or the response that comes back. Now, this is a fairly typical Inertia response. We have the component name, the URL that made the request, the version hash, and then the props being passed down to the front end. But take a look at all the props that come through when we request a new page of comments. We have the authenticated user, if there is one. We have the comments.

We have the authenticated user, if there is one. We have the comments. Now, we'd expect that one, but we also receive any errors. We receive this Jetstream object with information about teams and email verification. We receive the initial post, the user that created the post. We don't need any of this information. All we need is the paginated list of comments. But Inertia doesn't, by default, know that, so it's just going to send everything from the controller back down again. And that can increase the workload on our server, but it can also increase the payload size, meaning that each request takes just a little bit longer to get to the client.

And that can increase the workload on our server, but it can also increase the payload size, meaning that each request takes just a little bit longer to get to the client. Not a massive issue for a small use case like this, but as our application expands, we want to eek out all the performance we can, so it's great to know about these quick wins as and when they're available. And Inertia offers a very simple fix for this problem. I'm going to open up our pagination component where we have our links here, and for now, I'll hard code this property or this attribute that I'm going to add, but we'll come back and refactor that in just a moment. There is an attribute called only that you're able to attach to any Inertia link,

but we'll come back and refactor that in just a moment. There is an attribute called only that you're able to attach to any Inertia link, and only is a way of saying what is the only data that you want the controller to pass down to the front end when you click this link. So in our case, well, we only want comments, so we can absolutely specify that the only thing that should be passed down when you click on this link is the comments property. Shall we see what difference that makes in the front end? So we still have our initial request here. I'm going to come down to the bottom, and let's click the next button.

So we still have our initial request here. I'm going to come down to the bottom, and let's click the next button. Here's our second request, and take a look at the props. Now, instead of all that additional information, the auth, the post, the author of the post, the jet stream object, you just have the comments, and it has reduced the size of our payload. If you take a look at the size here, this is 2.5 kilobytes, whereas our original payload is 5.7 kilobytes, so less than half the size of the initial payload. Big difference, big saving just by adding one line to our links.

so less than half the size of the initial payload. Big difference, big saving just by adding one line to our links. Now, one thing to note if we go back to our PostController is this show method is still going to be executed in full when you ask for a new page of comments. It's just php. Inertia is a very simple layer between view and php. There's nothing magic going on. So what that means is that anything inside this array down here, well, that's still going to happen.

So what that means is that anything inside this array down here, well, that's still going to happen. The logic will still be executed. Now, imagine if instead of just wrapping this in a PostResource, which is pretty simple, we refresh the Post from the database first. What that means is that even though this won't end up being passed down to the front end, we will still make a database query here. So we're still doing all of that backend work, all of that logic, but then we're throwing it away because it never goes to the front end. Thankfully, Inertia has a workaround for this as well,

but then we're throwing it away because it never goes to the front end. Thankfully, Inertia has a workaround for this as well, and all we have to do is wrap all of our data in closures. And now, well, this will only actually be executed if it's going to be passed down to the front end. So with that little refactor in place, and with the only attribute added to our Inertia links, well, paginating becomes as small and as simple as it can get. The payload size is reduced. Our controllers are having to do less work, perhaps fewer database queries,

The payload size is reduced. Our controllers are having to do less work, perhaps fewer database queries, and our users get the best possible experience. Of course, if we're going to make this work across the board, we're going to need to refactor this so that we can add any property rather than having to hard-code comments as we have done here. Let's tackle that. Now, I think the simplest way to achieve what we're looking for here is to add a new prop to define props, but I'm going to switch to using the object syntax.

is to add a new prop to define props, but I'm going to switch to using the object syntax. So we'll have meta defined as an object. The type is object, and it's required. And then we'll have only as well. This is going to be an array, and the default will just be an empty array. And with that declared, well, we can come here and update this to use the only prop instead. The same is true here, and then we'll copy this, and we're going to paste it on the other links that appear.

The same is true here, and then we'll copy this, and we're going to paste it on the other links that appear. So here's the other link. We'll drop only in like so, and that will now appear on all of our pagination links. So if we don't declare pagination, only will be an empty array, and Inertia will say, I'm actually going to assume I need to load everything. But if we declare an only prop on the pagination component, it will limit to whatever we set inside that array.

But if we declare an only prop on the pagination component, it will limit to whatever we set inside that array. Let's go and update our existing code in our show component to factor in our new only prop. So we'll head into postShow. Here's pagination, and I'm going to set only to, well, you've got it, comments. I only want to load the comments property on the front end. Shall we see if it works? Here we are. We're on page 2 currently, so I'll click previous.

Shall we see if it works? Here we are. We're on page 2 currently, so I'll click previous. And if we go here and take a look at the preview, we're only loading the comments prop. If I go back to page 2 again, we should still only be loading the comments prop. But just to see if it is working as we'd expect, if we don't pass the only property, which could be the required use case under certain circumstances, you might want to force a reload of everything.

which could be the required use case under certain circumstances, you might want to force a reload of everything as you change the page number. Well, hopefully at this point, as we go back to page 1, let's take a look at the preview props. Yeah, it's loading everything. So there we are. What a great little nifty feature Inertia offers for limiting the data we actually have to pass back down to the front end. That's going to save our users, our controllers, and our network

for limiting the data we actually have to pass back down to the front end. That's going to save our users, our controllers, and our network a lot of hassle as traffic begins to increase. And over the span of many requests, think about how much data we're actually saving there. Very little that we had to do on the back end, but a big impact in the long run. Great work.