Question

I have a server side Python script that returns a JSON string containing parameters for a client side JavaScript.

# Python
import simplejson as json

def server_script()
  params = {'formatting_function': 'foobarfun'}
  return json.dumps(params)

This foobarfun should refer to a JavaScript function. Here is my main client side script

// JavaScript
function client_script() {
  var xhr = new XMLHttpRequest();
  xhr.open("GET", url, async=true);
  xhr.onreadystatechange = function() {
    if (xhr.readyState == 4) {
      options = JSON.parse(xhr.responseText);
      options.formatting_function();
    }
  };
  xhr.send(null);
}

function foobarfun() {
  //do_something_funny_here...
}

Of course, options.formatting_function() will complain that “a string is not callable” or something to that effect.

Upon using Chrome’s Inspect Element, under the Resources tab, and navigating the left sidebar for XHR > query, I find that client_script interprets options as below. foobarfun is seen as a string.

// JavaScript
options = {"formatting_function": "foobarfun"}

I would have liked client_script to see options as

// JavaScript
options = {"formatting function": foobarfun}

Of course, doing the following within Python will have it complaining that it doesn’t know anything about foobarfun

# Python
params = {'formatting_function': foobarfun}

QUESTION:
How should I prepare my JSON string from the server side so that the client script can interpret it correctly? In this case, I want foobarfun to be interpreted as a function object, not as a string.

Or maybe it’s something I should do on the client side?

Answer 1

There’s nothing you can do in the JSON to get the result you want because JSON has no concept of functions, it’s purely a data notation. But there are things you can do client-side.

If your foobarfun function is a global function (which I would recommend against, we’ll come to that), then you can call it like this:

window[options.formatting_function]();

That works because global functions are properties of the window object, and you can access properties either by using dotted notation and literals (window.foobarfun), or by using bracketed notation and strings (window["foobarfun"]). In the latter case, of course, the string doesn’t have to be a string literal, it can be a string from a property — your options.formatting_function property, for instance.

But I don’t recommend using global functions, the window object is already very crowded. Instead, I keep all of my functions (or as many as possible, in some edge cases) within a master scoping function so I don’t add anything to the global namespace:

(function() {
    function foobarfun() {
    }
})();

Now, if you do that, you can’t access foobarfun on window because the whole point of doing it is to avoid having it be on window. Instead, you can create your own object and make it a property of that:

(function() {
    var myStuff = {};

    myStuff.foobarfun = foobarfun;
    function foobarfun() {
    }

    function client_script() {
      var xhr = new XMLHttpRequest();
      xhr.open("GET", url, async=true);
      xhr.onreadystatechange = function() {
        if (xhr.readyState == 4) {
          options = JSON.parse(xhr.responseText);
          myStuff[options.formatting_function]();   // <== using it
        }
      };
      xhr.send(null);
    }
})();

Frequently, rather than this:

myStuff.foobarfun = foobarfun;
function foobarfun() {
}

you’ll see people write:

myStuff.foobarfun = function() {
};

I don’t recommend that, either, because then your function is anonymous (the property on myStuff that refers to the function has a name, but the function doesn’t). Giving your functions names is a good thing, it helps your tools help you (showing you the names in call stacks, error messages, etc.).

You might also see:

myStuff.foobarfun = function foobarfun() {
};

and that should be valid, it’s correct JavaScript. But unfortunately, various JavaScript implementations have various bugs around that (which is called a named function expression), most especially Internet Explorer prior to IE9, which will create two completely different functions at two different times.

All of that said, passing the names of functions around between the client and server usually suggests that you want to step back and look at the design again. Data should drive logic, but not in quite such a literal way. That said, though, there are definitely valid use cases for doing this, you may well have one in your situation.