This episode is for members only

Sign up to access "Laravel Cursor Pagination" right now.

Get started
Already a member? Sign in to continue
Playing
06. Fixing with cursor pagination

Transcript

00:00
Okay, so before we look at cursor pagination at the moment, the order of these are a little bit odd. It's very difficult for us to see how this matches up. The reason being is that we used a
00:10
factory to generate these out and the created updates are pretty much, yeah, all the same, obviously apart from the ones that we created, which I'm going to go ahead and delete. So what I'm actually going to do is just go for 15 records. I think that'll be enough. And I'm going to go ahead and manually update the created update for each of these. We could have
00:31
done that with our factory with some kind of sequence, but if we just go through and say this one was posted now and then this one was posted afterwards, that gives us a much better order because remember over in our post index controller, we're using latest, which orders by the creator that day. So I'm going to go through and update all of these so they're in a much better
00:57
sequential order and we'll come back to our page to have a look. Okay, so I've gone ahead and updated all of these. So these are now in a sequential created out order. And if we come over now, you can see we've got 15, 14, 13, 12, all the way down to six, and then we should see five. So this actually gives us a much better understanding of how this is working. If we hit
01:16
post on this and we post something new, the next one we should see when we load more is five. Obviously we don't. We see six because that's been offset by one by that post we've created. Same if we were to do this twice, that would be offset by two. So pretty much what we looked at in the last part, but just slightly different. So you can see here that we've got eight and seven again because
01:36
that's an offset of two and then six, five, four, three. So if we come over to our post endpoint here, we're going to very easily switch this over to cursor pagination. So to do this, instead of the paginate method, we use the cursor paginate method. Now with this, we're not going to get as much information because of the way cursor pagination works behind the scenes. It just
02:00
does not, it cannot give us as much information. And if we give this a refresh, you'll see here that we're missing quite a bit here. So we know how many are per page. That's pretty obvious. But with cursor pagination, we don't know the last page URL and any of the other information. So really what we just have is a next page URL, which to be honest, considering this will
02:21
eventually become null, is enough for us to implement what we need. In fact, we don't need to change anything about the implementation that we've created over on app.view because we use the next page URL here to give us that value that we make another request to. So let's try this out. I'm going to go ahead and hit load more. And sure enough, it works exactly the same way. Now at the
02:45
moment, this button will continue to make requests. So if we just check out our network tab here, this will still continue to make requests. Let's just go down and try this out. And it will actually break, yeah, because we are making a request to null technically here. So we can very, very easily fix that in just a moment. The point is now that now we have cursor pagination set up. And if we
03:07
come over to the database here and delete these just to test this out, when we make a request and add a new item to the stack and we hit load more, you can see it loads in exactly the same place because this sets the position which we want to load from. And that won't change when we add things to our database table. So although that was a long way of getting around to show you a very
03:33
simple method change over here, hopefully now that makes a little bit more sense. Cursor pagination is pretty complicated. You can go ahead and read up on it a little bit more to find out more about it. It's very SQL heavy, but this should have given you a really good idea as to when cursor pagination can be really helpful. Now finally, let's just fix this load more button issue up
03:55
because at the moment, we don't really want to show this if the next page URL is null. So a very simple if statement on here just to check that that's not null. And if we come over and give this a refresh and we hit load more, that disappears because the next page URL in our API endpoint will have turned to null.

Episode summary

In this episode, we're diving into cursor pagination and sorting out some quirks with our post ordering and pagination UI.

We start by fixing the order of our records. Because we initially used a factory to generate posts with nearly identical "created_at" timestamps, things looked weirdly ordered. So, we pare down our records to 15 and manually adjust their timestamps so they appear in true sequential order. This makes it much clearer how pagination moves through the records.

After that, we post some new items and see how the default pagination can actually get a bit out of sync if you add records while paging, which leads us neatly into introducing cursor pagination. We swap out our usual paginate method for cursorPaginate, and discuss some immediate differences. Cursor pagination doesn't give you as much info (like total pages or last page URLs), but for infinite scroll/load-more-type interfaces, just having the next page URL is all you really need.

We test out how it works in the UI—showing that it keeps the order intact, even when adding new records—and notice a bug where the "Load more" button keeps firing requests even when there are no more posts. To fix that, we simply add a quick check: only show the button if next_page_url isn't null. That cleans up the UI and makes everything work nice and smooth.

By the end of this episode, you'll have a much better understanding of cursor pagination and why/when it's a great choice, especially if you want more consistent loading of content as your data changes.

Episode discussion

No comments, yet. Be the first!