Preloading results in Ajax App

Rails
1

Hello Rails lovers!

I have a few general discussions that I have yet to find terribly
active. Perhaps all of the people busy on this front are…uh…busy on
this front.

So!

Ajax-only apps.
No degration.
Yes! Forget about degradation for a moment. Not willing to? Ok,
well…this question is for those who are willing…

Imagine developing an app that is one page - all actions render partials
on this page, probably with rjs. Already done it? Great, these questions
are for you then:

  1. Browser pre-loading. I am interested in NOT having the user sit
    around while my software loads and renders 10 results at a time, just
    like a ‘normal’ webpage. Not sexy. Updating and redrawing a part of the
    page is only the tip of the iceberg… I feel that it is time to be able
    to make sorting through larger amounts of data much more sexier, as a
    standard…

Here is my answer to this question, perhaps you have comments, or can
enlighten me with other answers.

— A Client-side pre-loading framework…Aka, on the page load we load
100 results into the browser, hide 90 of them in “display:none” divs,
then when we click on another page, no server calls are made, we just
use Element.show and hide to jump through the results. To me, loading
extraneous data on 1 sever call, saving 4 or 5 extra calls is much more
‘user-time-efficient’ than expecting the user to watch a rolly ball spin
over and over again to load a couple kb…

It seems to me that the only way Ajax is really going to make the web
sexy is if 3 out of 4 requests coming from a client are handled locally,
and the user wait time is reduced.

  1. Periodic “background” calls from the client update the server with
    client side changes…This method seems a bit more complex, would
    involve loading the page data into javascript objects, having the page
    actions modify those javascript objects, and then calling the server on
    a regular basis to sync…Writing messages in Gmail seems to give the
    illusion of working in this way, where it saves periodic drafts of
    messages without worry or concern on the user’s behalf. If the current
    copy of the message is not saved, and you try and navigate away, you get
    a popup asking what you want to do with the draft.

Rails seems like the ideal candidate for this kind of advancement in app
development. In the name of DRY, it would be useful to find the most
efficient paths, implement them once, and then walk away. Already it is
amazing to make a call like “sortable_element…” or “page.replace_html”

  • very sexy…Dragging and dropping is amazing! But on every drag, every
    drop - a server call? There must be a better way, and I am very
    interested in finding/developing it… As far as I know, no larger
    framework or plugin currently exists to really take applications to the
    ‘next level’…for example:

page.cache_and_paginate ‘div_container’, ‘hidden_div_series’, :partial
=> ‘single_result’

or

<%=droppable_element ‘add_to_favorites’, :sync => true %>

page.sync ‘add_to_favorites’,
page.sync ‘my_sortable’
page.sync :all

Ideas?

love
sudara

2

I’ve thought of this problem as well. But hidden divs wouldn’t cover
it for everything. I think the way to do this sort of thing is with
javascript arrays. Hidden divs would work for a standard table, but
not really so well for an autocompleting search box, for example.

I think a great way of doing this would be to have ajax begin loading
data into an array after the main page has loaded, and carry on in the
background 'til it’s all done. When some data is needed, the
javascript would then check if the data is already in the array. If it
is, it displays it, and if not, it loads it, displays it, then carries
on loading all the other data.

Of course, for any of this to be practical, we’d need someone to make
a ruby class to DRY it all up in rails, so all this can be done
easily. I don’t feel up to the task… it’s a pretty big ask of even
the most experienced rubyists. But that’s my idea of how it would work
ideally. Just my opinion.

-Nathan

3

I would like to hear from some more of the experienced rail-riders out
there about how they organize their ajax-heavy apps.

My initial impressions are these:

++++ MVC breaks down when developing a more advanced ajaxed app. Rails
is so sexy for standard apps, but the ajax integration feels
adhoc…Easy to throw some spice into a ‘normal’ app…not so easy to
build from ground up a complex application…RJS officially appeared in
1.1, so we are at the beginning of true integration. Currently, I feel
like I am developing MVC+javascript-mish-mash, not MVC.

Please do not read me wrong: I feel like a superhero writing code like
‘page.replace_html’ or ‘page.callMyOwnFunction’ It is wonderful to code
ruby/rails lines and receive complex javascript functionality, but I am
curious and wanting to be a part of future integration, or at least
gather the current ideas and methodologies…

If our User-At-Large is going to take web drag and drop/sub-page
updating seriously, there needs to be more major work to optimize data
loading, standardize user notification, etc. It is time that apps like
fluxiom are not unusual and targeting for the ‘high-tech’ web community.
But right now you cannot build a fluxiom in Rails. You can build fluxiom
in Rails if (and only if) you kick-ass at javascript, and either expect
the user to be ‘cutting-edge’ or write a lot of custom code to satisfy
user expectation.

++++ Because of the MVC breakdown, there is also a breakdown of the
standard sexy rails workflow of model-controller-action-view-partial…
I could not find a decent workflow path in Rails to take care of all of
my rjs calls. I rewrote and reorganized the code many times…First I
started with a the standard rails structure, then realized that it was
best for me to code all of my actions in one main controller, the
‘browse’ controller, as all of the events were ocurring on one page.

+++++ The flash[] system is great. For my all-ajax app, I built my own,
ignoring what was present. I’m sure not the best idea, but there seems
to be a need for displaying user-information - otherwise Ajax apps will
continue to be built with a ton of WET code.

Really, this is all just an excuse for taking a break from coding in the
best framework I have ever used. If you are in doubt while reading any
of this, please realize my interests are to ‘give back’ via sharing my
experiences, and putting a call out for some ‘best practices’

love
sudara

unknown wrote:

I’ve thought of this problem as well. But hidden divs wouldn’t cover
it for everything. I think the way to do this sort of thing is with
javascript arrays. Hidden divs would work for a standard table, but
not really so well for an autocompleting search box, for example.

I think a great way of doing this would be to have ajax begin loading
data into an array after the main page has loaded, and carry on in the
background 'til it’s all done. When some data is needed, the
javascript would then check if the data is already in the array. If it
is, it displays it, and if not, it loads it, displays it, then carries
on loading all the other data.

Of course, for any of this to be practical, we’d need someone to make
a ruby class to DRY it all up in rails, so all this can be done
easily. I don’t feel up to the task… it’s a pretty big ask of even
the most experienced rubyists. But that’s my idea of how it would work
ideally. Just my opinion.

-Nathan