Lessons: 14Length: 2.1 hours

Next lesson playing in 5 seconds

  • Overview
  • Transcript

2.7 Pagination

Our API clients might not want to receive all the query data at once. Instead, let’s improve this detail of our application and introduce pagination. This enhancement will add a slight layer of complexity to the implementation, but it will also provide extra value to consumers of the API.

Related Links

2.7 Pagination

So, we're pretty far away from normal development using the generators. We're actually introducing custom features into our code, something that adds extra value to the app. We're going to progress further in that path by introducing pagination. As you can see here in the tables controller, we are listing all of the tables. I have preemptively loaded our database with some more tables. So, if I type in the rail's console command, and type in table.all, you will see a lot of tables. Actually, let me just type in Herb.enable, which I've put in the Gemfile. You can check the source code. I'm gonna type Table.all now. We will see like 23 records or so. So, that's a lot of tables. Now I want to introduce pagination, because I want to list just a small portion of them, at least a portion at a time. Let's say I want to list for example, five each time. So, I'll need to introduce pagination into our application. But how do I do that? Well, let's start by going to the Gemfile and you can see that I already have the herb gem here in the development and task groups. And now I'm going to introduce the kaminari gem. The link to the kaminari gem is available in the description below. You can check it out for further details. For now I'm just gonna bundle the changes, so that I can have that library for us to use. Now with that we're gonna go back to the tables controller. So, the idea behind the kaminari gem is to have a parameter that's injected into our queries. Kaminari allows us to have some methods that will be injected into active record, which will make object retrieval a lot easier. So we need two parameters to do this. We need a limit and an offset. The way we do it with kaminari is by collecting a page parameter and a per page parameter, as well. This one we can define ourselves. Let's say, for example, we want five records at a time, and the page parameter is actually going to be retrieved from an attribute, or rather a parameter in the URL. We're gonna call it page, for example, like this. And then we'll inject both of these parameters in the query. We'll use page like so, and then we'll use per page and we'll use that argument as well, this variable. So, these two methods are injected by kainari into active record. The page method specifies the page we want. And per page sets the actual limit. So, if want five items per page, we will only get five. It's only a matter of changing this variable that the results will be different. Now there's one thing that we need to do. What if we just type in, for example, tables, like this? So, http://localhost:3000/tables. Where is the page parameter, after all? If we specify this URL like so, it will complain because parameters page will be nil. And when you shove a nil into page, that will complain. So, we need to specify a default parameter. Actually instead of this, I'm gonna provide a run here. So, the page will be either the page parameter or if it's no, then one will be assumed. And this will solve that challenge, if we save the file and go to the curl command. So, if you execute that command, let's see, local host 4300/tables whoops, it seems that we have an error. Let's see what the problem was. Let's go to this tab and the page method seems to not exist. So, most likely there's something that we forgot to add. Oh of course, we forgot to restart the server. Since we have done changes to the Gemfile, we'll need to start it over, so that the kaminari gem is loaded. Now, let's try and run this command again, and this time the per page method is undefined. Oh, this was my mistake. Instead of per page, it should only be per, so the method provided by kaminari is actually per and then you specify the page volume. But this was my mistake. So, let's try and do this again. Let's run the code command again and there you go. Now let's see something. So I have ID, the first one. Two, three, four, and five. So, we have five records at a time. Now, watch me as I paste a different page argument. Let's say, I wanna pass page two. I should have records from six to ten most likely. And look, there it is. So, six, seven, eight, nine right here, and ten at the very end, so that's awesome. We have introduced pagination just right. So, it is assuming that the default value for the page is one, and we are retrieving five records at a time. If I switch this back to ten for example, I will get a different scenario. So, if I choose to run this tables command again. I will see ten records instead of just five. So, there you go. With a single gem and a couple of lines of code, we have successfully managed to introduce new value, added value. The difference between using this in rails api or standard rails is really not existent, because this is all about the controller. It's all about data retrieval. There's really nothing interfering with the view system or templating system. Everything is part of the server side of things.

Back to the top