Debugging with the Closure Compiler Service API - AJAX

In reality, making the Closure Compiler Service API send the warnings that occurred in the compiling phase is as simple as assigning the value “warnings” to its “output_info” argument. Of course, the best way to understand this process is by example, so below I created one which accomplishes this in a basic way. Pay close attention to it, please:

<?php

// example using output_info = warnings
try {
 
    // include the autoloader class
    require_once 'Autoloader.php';
    Autoloader::getInstance();

    // create an instance of the file handler class and read the specified JavaScript file
    $fileHandler = new FileHandler;
    $js = $fileHandler->read();
   
    // build the array of arguments that will be passed to the closure compiler API
    $data = array(
         'js_code' => $js,
         'compilation_level' => 'ADVANCED_OPTIMIZATIONS',
         'output_format' => 'text',
         'output_info' => 'warnings'
    );
   
    // create an instance of the ClosureCompilerHandler class
    $compilerHandler = new ClosureCompilerHandler($data);
    // query the closure compiler API and get the compiled JavaScript function
    $response = $compilerHandler->sendRequest();
    $compilerHandler->sendHeader('js');
    // print to screen the compiled JavaScript function
    echo $response;
}
catch (Exception $e) {
    echo $e->getMessage();
    exit();
}

See how easy it is to instruct the API to send the compiling warnings? I bet you do! If you test the previous example on your own browser, you won't get any warnings, since the JavaScript function passed to the API has been coded correctly. If you're feeling adventurous and want to see how warnings are returned to the client, I suggest you deliberately alter the function (yes, you can be as evil as you want) and observe what kind of response you receive from the compiler.

And now that you know how to make the Closure Compiler Service API return warnings instead of compiled JavaScript code, it’s time to explore its debugging capabilities, so that you can learn how to put them to work for you.

In the last segment of this article I’m going to build a final example that will show how to instruct the API to send you the errors generated during the optimization process.

To learn the full details of this example, read the following lines.

A final example: showing compilation errors

As I said before, it’s ridiculously easy to make the Closure Compiler Service API return to the client the errors raised after optimizing a supplied JavaScript snippet. In simple terms, the process is reduced to first assigning the value “errors” to the “output_info” option, and then catching the corresponding response.

To demonstrate how to debug JavaScript code via this parameter, below I deliberately introduced a syntax error in the sample “createDiv()” function used previously, which will make the compiler complain loud and clear.

Here’s the amended version of the function:

(function.js)

function createDiv(idAttr, classAttr) {
    // create the div
    var div = document.createElement('div');
    // assign the 'id' attribute to the div element
    div.setAttribute('id', idAttr);
    // assign the 'class' attribute to the div element
    div.setAttribute('class', classAttr);
    append the div element to the document
    document.getElementsByTagName('body')[0].appendChild(div);
};
// call the previous function
createDiv('divid', 'divclass');

As you can see, the function now has a non-valid comment right before the statement that appends the div element to the DOM. At this point, if the corresponding JavaScript file is submitted to the compiler API through the following PHP script:

<?php

// example using output_info = errors
try {
 
    // include the autoloader class
    require_once 'Autoloader.php';
    Autoloader::getInstance();

    // create an instance of the file handler class and read the specified JavaScript file
    $fileHandler = new FileHandler;
    $js = $fileHandler->read();
   
    // build the array of arguments that will be passed to the closure compiler API
    $data = array(
         'js_code' => $js,
         'compilation_level' => 'ADVANCED_OPTIMIZATIONS',
         'output_format' => 'text',
         'output_info' => 'errors'
    );
   
    // create an instance of the ClosureCompilerHandler class
    $compilerHandler = new ClosureCompilerHandler($data);
    // query the closure compiler API and get the compiled JavaScript function
    $response = $compilerHandler->sendRequest();
    $compilerHandler->sendHeader('js');
    // print to screen the compiled JavaScript function
    echo $response;
}
catch (Exception $e) {
    echo $e->getMessage();
    exit();
}

then, the output returned to the client is not surprisingly a message containing the errors detected at compiling time:

Input_0:8: ERROR - Parse error. missing ; before statement
    append the div element to the document
               ^
Input_0:9: ERROR - Parse error. syntax error
    document.getElementsByTagName('body')[0].appendChild(div);
              ^

Not too bad, huh? Most likely you’ll be utilizing your own JavaScript debugger before optimizing your snippets through the Closure Compiler Service API, but it’s always useful to test its built-in debugging capabilities, in case you need to make use of them in some particular situation. 

Final thoughts

In this penultimate episode of the series, I provided you with a quick overview of the debugging capabilities that the Closure Compiler Service API offers for free. As you just saw in the examples developed previously, activating the API’s debugger is as easy as assigning the values “warnings” and “errors” to its “output_info” parameter. It’s that simple, really.

In the last chapter, I’ll be exploring a few miscellaneous features included with the API, which permit you to return optimization statistics to the client, as well as to serve compiled code in a printer-friendly format.

Stick to my recommendation: don’t miss the last part!