How to refresh screen data in JavaScript without making the page slow?

Question

I have a question in terms of code and NOT user experience, I have the JS:

$(document).on( "click", "input:radio,input:checkbox", function() {
        getContent($(this).parent(),0);
    });

The above JS gets the contents from radios and checkboxes, and it refreshes the page to show dependencies. For example if I check on yes, and the dependency is on yes, show text box, the above works!

What I want to know is, if there is a better way to do the same thing, but in a more friendly way, as this is at times, making the pages slow. Especially if I do a lot of ticks/checks in one go, I miss a few, as the parent refreshes!

Answer 1

If you have to hit your server to getContent() then it will automatically be slow.

However, you can save a lot if you send all the elements once instead of hitting the server each time a change is made.

Yet, if creating one super large page is not an option, then you need to keep your getContent() function, but there is one possible solution, in case you did not already implement such, which is to cache all the data that you queried earlier.

So you could have an object (a map) which has keys defining the data you're interested in. If the key is defined, then the data is already available and your return and use that data directly from the cache. Otherwise, you have to hit the server.

One thing to do, you mentioned slowness as you 'tick' things back and forth, is to not send more than one request at a time to the server (with a timeout in case the server never replies). So the process here is:

1. Need data 'xyz'
2. Is that data already cached? if yes, then skip step (3 and 4)
3. If a request being worked on? if yes, push the data on the request stack and return
4. Send a request to the server, which blocks any further request until answer for 'xyz' is received
5. Receive the answer and cache the data in an object (map) and release the request queue
6. Make use of data as required
7. I check the request queue, if not empty pop the next request and start processing from (2)

The request process is expected to be run on a timer because (1) it can time out and (2) it need to run in the background (not GUI preemptive)