Using script tag to pass arguments to JavaScript

Question

I need to implement a cross-site comet http server push mechanism using script tag long polling. (phew...) For this, I dynamically insert script tags into the DOM and the server sends back short js scripts that simply call a local callback function that processes the incoming messages. I am trying to figure out a way to associate each one of these callback calls with the script tag that sent it, to match incoming replies with their corresponding requests.

Clearly, I could simply include a request ID in the GET url, which is then returned back in the js script that the server generates, but this creates a bunch of unnecessary traffic and doesn't strike me as particularly elegant or clever.

What I would like to do is to somehow associate the request ID with the script tag that I generate and then read out this request ID from within the callback function that is called from inside this script tag. That way, all the request management would remain on the client.

This leads me to the following question: Is there a way to ask the browser for the DOM element of the currently executing script tag, so I can use the tag element to pass arguments to the contained javascript?

I found this thread:

Getting the currently executing, dynamically appended, script tag

Which is asking exactly this question, but the accepted answer isn't useful to me since it still requires bloat in the server-returned js script (setting marker-variables inside the script) and it relies on unique filenames for the scripts, which I don't have.

Also, this thread is related:

How may I reference the script tag that loaded the currently-executing script?

And, among other things, suggests to simply grab the last script in the DOM, as they are executed in order. But this seems to only work while the page is loading and not in a scenario where scripts are added dynamically and may complete loading in an order that is independent of their insertion.

Any thoughts?

PS: I am looking for a client-only solution, i.e. no request IDs or unique callback function names or other non-payload data that needs to get sent to and handled by the server. I would like for the server to (theoretically) be able to return two 100% identical scripts and the client still being able to associate them correctly.

Answer 1

It's most definitely possible but you need a little trick. It's a common technique known as JSONP.

In JavaScript:

var get_a_unique_name = (function () {
    var counter = 0;
    return function () {
        counter += 1;
        return "function_" + counter;
    }
}()); // no magic, just a closure

var script = document.createElement("script");
var callback_name = get_a_unique_name();
script.src = "/request.php?id=12345&callback_name=" + callback_name;

// register the callback function globally
window[callback_name] = function (the_data) {
    console.log(the_data);
    handle_data(the_data); // implement this function
};

// add the script
document.head.appendChild(script);

The serverside you can have:

$callback_name = $_GET["callback_name"];
$the_data = handle_request($_GET["id"]); // implement handle_request
echo $callback_name . "(" . json_encode($the_data) . ");";
exit; // done

The script that is returened by /request.php?id=12345&callback_name=XXX will look something like this:

function_0({ "hello": "world", "foo" : "bar" });

Answer 2

I know you would like to avoid discussions about changing the approach, but that's really what you need to do.

First, each of the script tags being added to the DOM to fire off the poll request is disposable, i.e. each needs to be removed from the DOM as soon as its purpose has been served. Else you end up flooding your client DOM with hundreds or more dead script tags.

A good comparable example of how this works is jsonp implementations. You create a client-side named function, create your script tag to make the remote request, and pass the function name in the request. The response script wraps the json object in a function call with the name, which then executes the function on return and passes the json payload into your function. After execution, the client-side function is then deleted. jQuery does this by creating randomly generated names (they exist in the global context, which is really the only way this process works), and then deletes the callback function when its done.

In regards to long polling, its a very similar process. Inherently, there is no need for the response function call to know, nor care, about what script tag initiated it.

Lets look at an example script:

window.callback = function(obj){
    console.log(obj);   
}

setInterval(function(){

    var remote = document.createElement('script');
    remote.src = 'http://jsonip.com/callback';
    remote.addEventListener('load', function(){
        remote.parentNode.removeChild(remote);
    },false);

    document.querySelector('head').appendChild(remote);

}, 2000);​

This script keeps no references to the script elements because again, they are disposable. As soon as their jobs are done, they are summarily shot.

The example can be slightly modified to not use a setInterval, in which case you would replace setInterval with a named function and add logic into the remote load event to trigger the function when the load event completes. That way, the timing between script tag events depends on the response time of your server and is much closer to the actual long polling process.

You can extend this even further by using a queueing system to manage your callbacks. This could be useful if you have different functions to respond to different kinds of data coming back.

Alternatively, and probably better, is to have login in your callback function that handles the data returned from each poll and executes whatever other specific client-side logic at that point. This also means you only need 1 callback function and can get away from creating randomly generated callback names.

If you need more assistance with this, leave a comment with any specific questions and I can go into more detail.

Answer 3

There may be a solution using onload/onreadystate events on the script. I can pass these events a closure function that carries my request ID. Then, the callback function doesn't handle the server reply immediately but instead stores it in a global variable. The onload/onreadystate handler then picks up the last stored reply and tags it with the request ID it knows and then processes the reply.

For this to work, I need to be able to rely on the order of events. If onload is always executed right after the corresponding script tag finishes execution, this will work beautifully. But, if I have two tags loading simultaneously and they return at the same time and there is a chance that the browser will execute both and afterwards execute botth onload/onreadystate events, then I will loose one reply this way.

Does anyone have any insight on this?

.

Here's some code to demonstrate this:

function loadScript(url, requestID) {
  var script = document.createElement('script');
  script.setAttribute("src", url);
  script.setAttribute("type", "text/javascript");
  script.setAttribute("language", "javascript");
  script.onerror = script.onload = function() {
    script.onerror = script.onload = script.onreadystatechange = function () {}
    document.body.removeChild(script);
    completeRequest(requestID);
  }
  script.onreadystatechange = function () {
    if (script.readyState == 'loaded' || script.readyState == 'complete') {
      script.onerror = script.onload = script.onreadystatechange = function () {}
      document.body.removeChild(script);
      completeRequest(requestID);
    }
  }
  document.body.appendChild(script);
}

var lastReply;

function myCallback(reply) {
  lastReply = reply;
}

function completeRequest(requestID) {
  processReply(requestID, lastReply);
}

function processReply(requestID, reply) {
  // Do something
}

Now, the server simply returns scripts of the form

myCallback(message);

and doesn't need to worry at all about request IDs and such and can always use the same callback function.

The question is: If I have two scripts returning "simultaneously" is it possible that this leads to the following calling order:

myCallback(message1);
myCallback(message2);
completeRequest(requestID1);
completeRequest(requestID2);

If so, I would loose the actual reply to request 1 and wrongly associate the reply to request 2 with request 1.

Answer 4

It should be quite simple. There is only one script element for each server "connection", and it can easily be stored in a scoped, static variable.

function connect(nameOfCallback, eventCallback) {
    var script;
    window[nameOfCallback] = function() { // this is what the response invokes
        reload();
        eventCallback.call(null, arguments);
    };
    reload();

    function reload() {
        if (script && script.parentNode)
            script.parentNode.removeChild(script);
        script = document.createElement(script);
        script.src = "…";
        script.type = "text/javascript";
        document.head.appendChild(script);
        // you might use additional error handling, e.g. something like
        // script.onerror = reload;
        // but I guess you get the concept
    }
}