Making this work strictly for AJAX / JSON objects

[iwasrobbed]

Right now the plugin loads an entirely new page and strips everything except what it needs for the new content. This adds additional hits to the database (for unrelated content elsewhere on the page) when really all we are trying to load is specific objects as JSON or partials from the webserver.

It would be nice to have an option to supply an AJAX route and get the data directly from there instead of the current methodology. This could even be it's own plugin since this one seems to be more for those who can't control what is sent from the backend.

Any thoughts or plans to do something like this in the future? I guarantee a lot of people would use this feature. Thanks!!

[lukeshumard]

I'm actually working on this right now! I should have a version of it working within a month.

[iwasrobbed]

@lukeshumard awesome! For the time being, I just modified the kickOffAjax() method to do this for me: https://gist.github.com/906235

I was wondering though, what are you guys using the callback.call() method for in kickOffAjax()? I'm not sure I understand it.

[lukeshumard]

The callback.call() method is used to call the callback function specified in the user's script. The first argument for .call() is to specify what this is, and the second is all of the data being returned. for example, if you want to add a class of 'new' to all of your newly appended content and a class of 'scrolled' to your container, you could do the following as your callback...

function(newElements) {
    $(newElements).addClass('new');
    $(this).addClass('scrolled');
}

You can read a tiny bit about the .call() function here.
http://odetocode.com/blogs/scott/archive/2007/07/05/function-apply-and-function-call-in-javascript.aspx

[lukeshumard]

Thanks for making the gist!

I'm curious, though, why wouldn't you make your $.ajax() call with a dataType of JSON? What I'm working on is something similar to that, where instead of the newly acquired content being appended to the container via .load, it's then interpreted by the callback function. Since the result would be JSON, I'm guessing most developers would use it in conjunction with Templates, Tempo, or a similar plugin/concept.

[iwasrobbed]

Thanks for explaining callback!

The reason I returned HTML is because I wanted to let the server generate the HTML fragments instead having to get JSON back and then use jQuery to template the fragments.

I think it's just a matter of preference, but the more view code I can keep on the backend, the more maintainable my javascript will be in the future. I'm using Rails, so telling the server to do all the work was as easy as saying = render @objects and it returns it via AJAX.

There will be some users who will only get a JSON response (let's say they are using someone else's API and wrapping it into HTML) so they need JSON, but there will also be others who might want the server to generate the HTML and need something similar to what I have.

[lukeshumard]

That makes sense why you would want all the code to be generated in the backend instead of JavaScript (where it doesn't really belong). It's definitely a better practice than having rendering in your script. I'm pretty sure you can still keep this separate if you use jQuery Template, although I'm working with another developer on sorting that.

I'm not familiar with Rails, so I'm assuming = render @objects...renders the data as html? Is there a way to have your infinite scroll path point to a control that just renders the html you want, and doesn't include all the elements .load() would trim out? If you still want no-js users to get the next full page, you could always use the pathParse option to override it for js users and call the modified control to only grab appended content.

[iwasrobbed]

Yeah if you use a templating engine, that's just as good since all of your views are in one place. That's really the key idea I guess.

In Rails, using = render @objects I can send out only the HTML fragment that I need so there's no need to scrape the page or have the database get hit by other objects that are on the page that don't end up getting used. Other backend frameworks can do similar things. That is the only limiting factor right now for people using infinite scroll on a backend they control is that it hits the database unnecessarily and still has to load resources that it may not use. On a site with a lot of dependencies, this can make a huge difference in response time.

Most backend frameworks have a way to generate AJAX through a specified route. In my case, I modified the standard route /users/1?page=1 to deliver HTML fragments if the route is called via AJAX, otherwise it delivers a page like normal. Some people may have a scenario where the landing page of pagination is different than where they want the ajax to be called from though (I almost did it this way). For example, the landing page is users/1?page=1 but their ajax calls would goto users/1/ajax?page=1. Thanks for the tip on pathParse but I'm actually not a fan of "progressive enhancement" anymore :)

These are just some items that I ran into while going through this process, so maybe they'll be helpful to you!

[lukeshumard]

This is in for version 2.0b.110415.

You can now specify the options of dataType of 'html' or 'json', as well as appendCallback(lines 217-218).

dataType is self-explanatory, and appendCallback is a boolean to specify if you want your (successful) AJAX result to be appended to the container. Setting appendCallback to true makes the plugin work exactly as it did before, using .load() and appending the results into a documentFragment.

[iwasrobbed]

Thanks again Luke!