Contact
You can contact us by completing the form below or email us directly if you prefer
Email Us
info@redwarp.com
There is much discussion about when and where to deploy infinite scrolling on your web pages. I do not intend to enter into those discussions here, only to prove the mechanics of how to deploy it.
Please do your own research as to whether yours is a best-use-case scenario or otherwise. Infinite scrolling is a very useful way to show your content but there are cases when it is a great way to go and there are cases when it is not.
The key elements you will need for a successful implementation are as follows:
Starting with the template, we need to maximise efficiency so your template (without the data representing the pages) should be as complete as possible so that we transfer this once and once only.
The dynamic content can then be injected into our template on the client side, usually page by page.
Whilst it is preferable from a data transfer point of view, to only send data of a purely dynamic nature. There is a trade-off here against client side processing becoming unnecessarily complex.
Taking a simple example, display a list of real-estate properties. We might load the initial page with 10 properties and when the user has scrolled through all/almost all of these, we trigger a callback to the server for another 10. Each of the properties will typically have a thumbnail image, some description text and various other "asset" icons which will all be dynamic. The block of html representing each property will have its own sub-template and you will need to decide, is it easier in terms of coding, to render these blocks of html on the server side and then send then (already rendered) to the client-side, or whether to minimise the traffic by sending the raw data and increasing the complexity of client-side processing by first rendering the received data into its required html before injecting it into your page template.
As you will have server-side code already setup to render your page items content, I prefer not to have to recreate the same rendering code on the client side as well. Therefore each callback to the server will produce a pre-rendered block of html ready to simply append to the block of html that is already present in the DOM on the client side.
This way, the client side coding is much less complex and is simply a matter of reading our currently displayed dynamic part of the DOM, appending our data (block of html) from our callback result and rewriting the dynamic element of the DOM with our new dynamic content.
Triggering a call from client-side to request more content for your displayed page, can get a bit tricky because you need to de-bounce your trigger (to stop it issuing multiple calls before the first one has been fulfilled). The easiest way to do this is to disable your trigger function as soon as it is activated. Then only reactivate it after successful completion of the (ajax) call. You can also drop in a timeout such that it will re-enable in any event, this can be useful if your server may occasionally fail to respond (possibly due to network issues).
With CodeIgniter, it is relatively simple to create an ajax response function that can retrieve the next page of data from the DB and return the json encoded html block ready to be appended directly to your page content. This function will need to be supplied with at least a page number from the client side trigger mechanism so you need to keep good control over this otherwise you can end up with pages missing or out of sequence. It depends upon your application, sometimes missing or out-of-sequence pages do not matter of course.
You can see an example of this in practice below
We are happy to help with your site and if you wish to discuss your needs we will be delighted to hear from you on this or any of our other areas of expertise.
You can contact us by completing the form below or email us directly if you prefer
info@redwarp.com