Intro, and Project Demo

In this video we will take a quick demo of the Pagination, Filtering, and Sorting using Twig.

Please note that this course expects you to have completed this previous course or have equivalent knowledge.

This demo will cover the functionality that we will implement in the four different scenarios we have:

• Symfony 3 with Twig
• Symfony 3 with FOSRESTBundle, as an API
• Angular 1.5 talking to our Symfony 3 API
• React 15.2 talking to our Symfony 3 API

In the video we will see how the site operates using Twig.

By the end of this series we will have implemented the same functionality but without having to do full page reloads whenever we change the query.

At this point I should point out that if you haven't already done so, I would recommend completing this course - or having a similar level of knowledge - before starting this course. We will use the code from that course as the starting point for this course.

All the logic will be done on the server side. This means that we must modify the query string in order to paginate, filter, and sort our data.

Here are some examples:

http://api.symfony-3.dev/app_dev.php/posts

This is the root URL for getting access to our Blog Post data.

Once we have added the paginator bundle, we could also hit the following URLs, which would be functionally identical:

• http://api.symfony-3.dev/app_dev.php/posts?page=1
• http://api.symfony-3.dev/app_dev.php/posts?page=1&limit=10
• http://api.symfony-3.dev/app_dev.php/posts?page=1&filter=&limit=10
• http://api.symfony-3.dev/app_dev.php/posts?direction=&page=1&filter=&limit=10&sort=

This is to prove that the query string ordering doesn't matter, and that leaving any of the parameters as blank (e.g. filter=) would mean they don't have any impact on the result.

Given this, we could then assume:

http://api.symfony-3.dev/app_dev.php/posts?page=1&limit=20

Would show us page 1 with 20 records / blog posts on the page.

http://api.symfony-3.dev/app_dev.php/posts?page=2&limit=5

Would show us page 2 with 5 records / blog posts on the page.

And so on.

We will come back to this throughout the course.

Pagination

For pagination in Twig we get this as part of the template included in the KnpPaginatorBundle.

This means with just a single line of config, we are going to get ourselves a nicely styled and formatted Bootstrap 3 compatible paginator. Flippin' awesome.

We'll see just how easy this is to add into our project in the very next video.

Of course in our API we won't need this at all. However, that doesn't mean we get away with doing nothing - there will be a little work required to make it behave.

And then in React and Angular we will make use of existing Bootstrap components for the respective library / framework. More on this in the specific videos. In both cases we will need to provide extra info to the paginators so they can correctly show the amount of pages, and so on.

Sorting

We need to make sure that we can sort data.

We will achieve this through clickable table row headers. On first click, the row will be sorted 'ascending', on second click 'descending', third will flip back to 'asc', and so on.

We'll need a way to add this information to the query string, and then to send the amended query to the server, so as to get back the correct results.

A likely bug will be in that sorting works correctly on page 1, but on page 2 the order reverts. Best keep an eye out for that one.

Filtering

JavaScript is actually pretty fantastic at filtering and sorting data. It's kind of a shame that we won't get to really see how powerful it can be at this task.

However, we will again need a way to provide an input for our users to filter the resulting data set, and ensure that as the filter input changes, so too does the API query / response.

We will do this by watching for input changes, and then re-running the updated query accordingly.

Server Side Vs Client Side

For all of these tasks we could have just allowed our users to do a big GET request and then let them worry about it. That becomes a little impractical as your database (almost) inevitably grows.

It's really entirely dependant on your circumstances. In general, it makes sense - in my opinion - to have the server worry about this stuff. It scales better, and in the case of Symfony, KNP Paginator Bundle does a remarkably good job of making this task a cake-walk.

As ever though, use your own personal judgement.