Pagination is a common programming problem to solve - nearly all projects we work on we’ll need pagination in one form or another. As a result, it’s something that is good to get right early on so that we can re-use our code over and over again and not spend anytime reinventing the wheel each time it comes up.
In order to follow through this article, I’ll assume you have at least some knowledge in the following:
- Laravel 4
- Angular JS
As part of every one-page application, our views and view logic should probably be apart of Angular JS, so I’ll be using that assumption in this article. We’ll be touching base on a number of concepts from both frameworks:
- Laravel 4 routing
- Angular JS resources
- Angular JS services
Because most of the logic is going to be on the client-side (rendered and parsed within the browser), that frees up a lot of time for our server to be doing things it might otherwise be doing. This means our server-side implementation will be much simpler than the traditional method, and so we’ll get the structures we need in place first, on Laravel 4.
Setting up the route
In this example we’ll pretend that we want to get a number of posts - so we’ll setup a route for that request. I’ll assume here that you already have a Posts model setup.
In order to be able to return a Paginator object as it does in this article, please see: Making the Paginator API-friendly in Laravel 4.
Here all we’re doing is telling Laravel that all requests to /posts will be served by our anonymous function which is just going to return a list of posts, already paginated. What’s that going to do? Well, it should return a JSON object that looks something like this:
This is a JSON object returned by our server that gives us some information such as:
- The last page (in this case 9)
- Which page we’re currently on
- How many items we’re returning per page
- The array of results for this current page
- The total number of records
For those of you who have worked with Laravel’s pagination library before - this probably looks pretty familar. That’s because Pagination in Laravel simply returns an array with the relevant properties. The trick is making this work and gluing it all together on the front-end.
Creating the resource service
To access the server, we’re going to setup a Post resource that we’ll call from within our angular controller to make the request to our server for the paginated data. Remember to do this you need to have the ng-resource dependency available for your application.
This creates a Post service that we can inject into our controllers (or directives) to make requests to the server for post records. Now we can use this in our controller and setup our pagination!
If you like to use ng-resource, see my article: using ng-resource in a more RESTful manner.
Setting up the controller for pagination
The most complex part of this whole task is creating the controller and having it set the appropriate scope variables for pagination in our view. What we’re going to do however, to keep our controller nice and clean - is setup a second service called Paginator, which will inject a new pagination object into our controller for this functionality. This means that our controller only needs to tell the paginator what service to use for the querying, as well as pass some data to our view to manage the navigation. Let’s build it!
This is all very simple - and pretty much textbook Angular. What we’re doing is making a call to our /posts/ route on our server via the Post service, and assigning a posts variable to $scope so that we can work with it in our pagination directive, which we’re now going to build. There’s a fair bit of code in the next method, so read it carefully and I’ll go through it with you in a moment.
There’s a lot going on here, so let’s break it down step-by-step. First we’re defining our directive, called “pagination” on our module. We’re then defining it by creating a link function, but also restricting the scope to what we pass in through the view. Let’s look at that.
What this will do, is create a two-way data binding to an attribute on our directive called “pagination” and store it on a scope property called “results”. Why is this important? It ensures that our directive acts completely on its own with no outside influence (such as $scope pollution) - and we simply tell it what the resulting data set is from our server. I’ll cover this in a little more detail below when we get to the final step.
After this, we start working with our link function and we’re creating a new function, called paginate. What this method is doing is looking at the result set that has been passed into the directive and setting the required variables and properties that we’ll need in our view below. Properties such as the current page, the total number of records, how many pages there are - as well as a page array that we’ll use later to generate the paginated links. And finally, it creates a number of functions that we’re assigning to the view for usable functionality - aka, functions that the user themselves can execute for their desired results.
Next, you’ll see another function called pageChange. This is a very simple method that simply watches the the currentPage and emits an event upwards (so that our controllers can respond) with the new page that’s been requested.
Finally, you’ll see two $watch calls on scope that watch results, and currentPage properties - and pass it the required callbacks that will handle the functionality once those properties change.
This is all fine and well - but there’s one thing missing. We have not yet implemented this in our view, or even got any pagination HTML! Yikes! That’s what we’ll do now - we’ll create the HTML that our pagination directive will be responsible for, and provide all the functionality that our end-user will expect. Let’s update our pagination directive from before, by adding a new property to the directive definition called template that will handle this for us:
You could also put this in a templateUrl property and have it loaded from the server, and even disable certain links based on the current page.
As you can see, and as you would expect - our pagination template has all the required functionality you would need from such a requirement. Next and previous links, first and last page links, as well as a full paginated page list. Feel free to add your required classes and style it as you need!
The final step, is to wire this up in our view, so let’s do it.
Remember how we stated earlier that we’d pass in the results to our pagination directive? Well that’s exactly what’s going on here - this HTML sits in the template that our controller manages, and we simply call the pagination directive and pass it the name of the variable that contains the returned results.
And there you have it - an isolated pagination directive that responds to data requests, as well as notifies our controllers when changes are requested!
Pagination is not exactly a simple piece of functionality, especially if you have to re-write it all the time. Hopefully this article has demonstrated that not only is it super easy (and fast) to write excellent, modular features in Angular - but has also proven that good practice is an easy objective to achieve. Comments, feedback and criticisms welcome as usual! :)