google closure compiler and json

Question

I have a json string that I parse and then access the properties of the object with the dot notation. However, in the google closure compiler, the dot notation (MyObject.P

Answer 1

EDIT: the @expose directive has been deprecated

---

Google Closure Compiler lets you specify directives on how compilation should be done through annotations.

See: https://developers.google.com/closure/compiler/docs/js-for-compiler

Properly using @expose and @type you can preserve the name of a property in your code.

It is possible to safely decode a JSON string into an object and access that object using the dot notation. You'll be also able to stringify back the data.

-

Let's make an example:

You want to parse an array of objects. Every object represents a "size", with the properties w for width and h for height.

Declare a prototype for the size object and expose its properties w and h

function size() {}

/** @expose */
size.prototype.w = 0;
/** @expose */
size.prototype.h = 0;

Then you want to put the JSON parsed data into an array called data.

Using @type you declare that data is going to hold an array of object of type size.

function main()
{
    /** @type {Array.<size>} */
    var data;

    // string built up just for example purposes
    var response = '[{"w": 10, "h": 20}]';

    // parse the array
    var data = JSON.parse(response);

    // access data with dot notation!
    console.log(data[0].w+ "    "+ data[0].h);
}

main();

Answer 2

You basically have two choices:

1. use object array access using the string literal (aka MyJsonObject['PropertyName']) this is the simple solution.
2. create a extern file describing the properties in your JSON object and then use dot notation (aka MyJsonObject.PropertyName). This requires more maintenance but allows the compiler to type check the properties if you provide type annotations in your extern description.

Answer 3

If the only JavaScript you are going to write is accessing external json, then it defeats the point of using the compiler. However, if you have even a trivial amount of JavaScript which does work besides parsing your json into domain models then the compiler may be useful.

In our parsers we access our data via bracket notation so we can get the data properly. From there we stuff the data into our own models, which we use the . notation on. These get wildly renamed, gives us type checking and all of that goodness.

Edit>> For data I use the XHRManager. This is one seriously nice class. When I get a data event from that pool I handle it as follows.

/**
 * @private
 * @param {goog.events.Event} evt The event recieved from the XhrIo.
 */
mypath.MyClass.prototype.onDataRecieved_ = function(evt) {
  if (evt.type != 'complete') return;
  var xhrIo = evt.target;
  var data = xhrIo.getResponseJson();
  //do somethign!
};

I have to warn you, my XHRManager handling still leaves a fair bit to be desired. I only refactored my code last week to start using it.

For parsing I do this: (This is some raw stuff from my code base, so ignore some of the ugly.)

our.class.path.ContestJsonParser.prototype.setContestProperties =
    function(contest, element) {
  contest.setName(element['description']);
  /**
     * @type {!number}
     */
  var timeAsInt = element['startTime'];
  contest.setScheduledStartTime(timeAsInt);
  var clockModel = contest.getClockModel();
  if (goog.isDefAndNotNull(element['period'])) {
    clockModel.setMatchState(element['period']['periodName']);
    clockModel.setStateStartTime(element['period']['periodStartTime']);
  }
  //TODO (Johan) this needs to change today to consider the rest of the stats
  //information
  var stats = element['statistics'];
  if (goog.isObject(stats) && goog.isDefAndNotNull(stats['score'])) {
    var score = stats['score'];
    contest.setMatchScore(score['home'], score['away']);
  } else {
    contest.setMatchScore(undefined, undefined); // clears score.
  }
};