Front end Pagination
The Google definition of pagination is “ the sequence of numbers assigned to pages in a book or periodical.” what we as programmers probably think of when we see or hear pagination is most likely tables… At least that’s what I think. I recently decided to add pagination to my mock Telsa charging web app (E-ccentric) my current implementation of tables and my own lack of CSS skills made it so that over 17 items in my table made the page not scroll to see the rest of them and also who likes to scroll that far down anyway? Pagination would allow me to control and limit how many items in my table could be seen at a time and then if there’s some leftover, allow buttons of numbers or arrows to dictate the next page. So what types of pagination are there?
Front end vs server-side pagination
So some people may think pagination is just pagination and how you achieve that effect doesn’t matter. It’s a little bit more nuanced than that. There are two distinct ways to achieve pagination, those are done via front end or server-side pagination.
Server-side pagination means that the backend will only fetch for a specific number of articles or items to populate your tables and then fetch new ones every time you wish to view another page or change how many are viewable. This has its own list of pros and cons.
Pro: Faster when dealing with thousands or tens of thousands of data entries. Instead of your server having to fetch the entire list and then perform operations on it. It will perform those operations on the back end which is much faster and just fetch 10 or 20 and present them to the front end. This can be done incredibly fast as that’s where SQL shines when manipulating thousands of data entries such as this. This will give a much faster initial page load.
Con: A lot of fetch requests for possibly very little data. If your application isn’t going to be used by millions of people and only will be fetching perhaps 100 data entries or even less. Having one fetch request, and loading them all into your react state or redux store will be much more efficient. So server-side pagination is much more suited for large data sets.
Front end pagination which is the method I decided to go with is the process of fetching the entirety of the data and storing it on your front end framework data structure and then splicing and created a new array based on parameters set by the user's preference of how many they wish to view per and which page they are currently on. This data is then presented to users instead of the original fetched data. This type of pagination is extremely fast after the initial page load as you no longer have to fetch the data anymore. As long as you aren’t dealing with large data sets this will be your best bet as the benefits are amazing until a certain in data is reached then your users could be waiting seconds for the entirety of their data to be fetched.
Pro: Only one fetch request is required and then the data is manipulated on the front end. This makes gives the application a very fast subsequent page load. This is perfect for applications that won’t be dealing with millions of entries of data and won’t be bogged down by such a large and slow fetch request.
Con: The first con is that if your application is dealing with thousands or even millions of entries of data that first fetch request can be painfully slow. Take a few seconds too long to load user data and they move from your website to someone else’s. So it’s very important to realize from the beginning how you are going to deal with the data inputted into your backend and what is the end goal of your application.
Con: Another con that I only recently discovered while attempting to implement this type of pagination is that technically all items or pieces of data that are added to the new data structure are old. I shall explain this in a bit.
Problems I ran into with front-end pagination and how I’m attempting to solve them.
What do I mean when I say the paginated data is old? I’ll take an example right out of my own application.
The issue that I had when implementing frontend pagination is that now there are two sources of truth. The data coming from the backend is the most updated form because every change on the objects that I fetch automatically updates the backend with existing changes. The paginated data will however not get these new changes unless the entire list is fetched again and we splice and segment the data once more with the newly updated entries. This can cause an issue as I’m about to explain to you.
In my backend, I store every transaction of charges that are done. The price, length of charge, date, and if that charge has been paid or not. My application gives you the choice to pay now or later on at your earliest convenience. This is where the problem begins. If a user decides to click pay later the transaction will be saved to the database with a false boolean of the paid key of that transaction object. When fetching for this data it will correctly showcase that it hasn’t been paid and populate the table. When an entry hasn’t been paid for that transaction alone it will show a pay now button which will then submit a patch request to the database to update this object with paid having a true boolean. The paginated versions of these transactions (what the user sees) do not get updated because that data is not the current version populating the list and thus we now have two sources of truth.
What I plan for next week
How I plan to fix this and make sure that the paginated data is always the most up-to-date version of data from the backend is that every request to the backend such as the patch request to change paid from false to true empties the list of paginated data structure and fetches for the data again. This slight change should trigger conditionals I have in place that check to see if the code that paginates the data has been called and if not will call and get fresh data direct for the newly fetched redux state. I have not tested this theory yet, but I’d like to think that you enjoy seeing how I would think to solve this problem so that both data sets are the same always.
If you’ve read this far thank you for taking the time and I hope you enjoyed it. I shall update you next week on if this method worked and if not what I did to fix it instead!
