JSON Community

Welcome to JSON.com!

2015-10-12T09:05:33+00:00

JSON.com has existed on the Web since 2006. It’s changed hands a number of time looking for a sustainable home.

BigBlueHat has most recently offered to curate a community via the collaborative awesome of GitHub.

If you are interested in participating, please reach out via GitHub. Send in Pull Requests with openly licensed content, links, etc.

Let’s build this one to last. :wink:

Send JSONP Cross-domain Requests

2013-12-16T00:00:00+00:00

Cross-domain Requests

In developing web applications it’s commonplace to send and receive data to APIs (Application Programmable Interfaces) that exist on other domains. This cross-domain communication is often performed directly in the browser, on the client-side using JavaScript. Cross-domain communication can be accomplished using a server-side languages like Python, Nodejs, PHP, etc., however for cases where responses from cross-domain requests are utilized in the browser, JavaScript can save time and simplify development. Addintionaly, JavaScript requests are asynchronous— meaning they can be run in parallel with other processes. For example, JavaScript requests to other domains can be processed asynchronously while the page is still loading.

Same-origin Policy

Same-origin policy is an important security concept in client-side programming languages including JavaScript. This policy is observed by all web browsers and limits scripts running on a site to only sending requests with the same site. Browers use a combination of port number (e.g. 80) and hostname (e.g. my.domain.com) to determine the scope of the ‘site’. There are however exceptions to the same-origin policy, including using the HTML <script> tag to retreive a dynamically generated JavaScript file from an external site. The most prominent of method of exploiting this exception is JSONP.

JSON with Padding (JSONP)

JSONP uses the <script> tag to retreive remote JavaScript code containing formatted JSON data with a function call wrapped around it. The data is not parsed, rather it is evaluated by the JavaScript interpreter.

A typical JSONP request may look like:

<script type="application/javascript"
  src="http://remote.domain.com/data/?callback=jsonpcallback&id=123">
</script>

The dynamically generated JavaScript file may look like:

jsonpcallback({
  "id": "123",
  "comments": "6",
  "name": "sample"
});

The “padding” in JSONP refers to the function call that wraps the formatted JSON object. This padding isn’t always a function call. Though not common, padding could also be a variable assignment:

var data = {
  "id": "123",
  "comments": "6",
  "name": "sample"
};

The purpose of the padding is to allow a means for the formatted data to be put to use in the application.

jQuery for JSONP

The jQuery JavaScript library has functions to make using JSONP a snap.jQuery’s $.ajax() function will automatically handle <script> tag injection and response handling (i.e. calling the ‘callback’ function).

$.ajax({
  //JSONP API
  url: "http://remote.domain.com/data/?callback=jsonpcallback&id=123",
  //the name of the callback function
  jsonp: "jsonpcallback",
  //tell jQuery to expect JSONP
  dataType: "jsonp",
  //tell YQL what we want and that we want JSON
  data: {
    id: "123"
  },
  //work with the response
  success: function(data) {
    console.log(data); //formatted JSON data
  }
});

console.log(data);

{ "id": "123", "comments": "6", "name": "sample" }

Alternatively, if jQuery is not available- which is often the case when developing embeddable widgets- raw JavaScript can be used. The following is minimal JSONP implementation:

//callback function
function jsonpcallback(data) {
  //do stuff with JSON
  console.log(data);
}

//create HTML script tag
var script = document.createElement('script');
script.src = "http://remote.domain.com/data/?callback=jsonpcallback&id=123"

//inject script tag into head
document.getElementsByTagName('head')[0].appendChild(script);

Bootstrap Data to a Page

2013-12-11T00:00:00+00:00

What does “bootstrapping” mean exactly? Hard-coding your data to the page using synchronous server-side template.

Most developers face the challenge of sending data from their server-side to the client-side to be used JavaScript. There are several solutions for this. Among the most common is creating an REST endpoint that can be consumed with asynchronous javascript, often using the jQuery Ajax function.

How is page load time affected when loading data asynchronously? Does the user’s experience depend directly on this data?
Is there unecessary overhead creating an REST endpoint?
Does the REST endpoint need to be secure? Authenticated? CSRF Tokenized?

Depending on the answers to these questions, bootstrapping may be an elegant solution for getting the data to the client-side quickly and with minimal development.

It typically looks something like this on the server side:

<script type="text/javascript">
//bootstrapped data with server-side template
var bootstrap = {
  "app_id": "",
  "session_id": "",
  "title": '',
  "price": "",
  "confirmation": ""
};
</script>

It looks like this when it’s rendered on the client side:

<script type="text/javascript">
//bootstrapped data rendered on client-side
var bootstrap = {
  "app_id": "a1b2c3",
  "session_id": "x0y9z8",
  "title": "My Cool App",
  "price": "1.99",
  "confirmation": "Thanks for purchasing our app."
};
</script>

This boostrapped JSON object can now be called with JavaScript immediately when the object is rendered by the browser:

console.log(bootstrap)
// { "app_id": "a1b2c3", ... }

console.log(bootstrap.title)
// My Cool App

Note: it’s best to put the bootstrapped object near the top of the page so it can used immediately, even before remaining html/css/javascript is loaded.

The key benefit of the bootstrapped object comes in the time saved when not having to use asynchronous JavaScript to call data from a REST endpoint. If you typically use jQuery Ajax to do this, 100-500 milliseconds of prerequsite load time would be added just to gain access to the jQuery.ajax() function. Any ajax request(s) retreiving data from a REST endpoint comes with additional load time expense.

If your app depends on this data, synchronously loaded (aka “bootstrapped”) JSON data will make your app snappy and your users happy. Not to mention, because of the server-side templating, REST endpoint security considerations are nullified.

Unleash the Power of Nesting

2013-12-10T00:00:00+00:00

The use of nested JSON object often allows developers to break out of the common relational schemas employed in databases like MySQL and MSSQL. When not limited to a shallow data schema based on rows and columns, data can take on new strucutres to better align with development needs. When JSON is used in a persitence layer, nested objects can often be used to replace simple relationships that might have existed in a relational data schema.

Nested JSON Object

An example of an ‘employee’ object stored in JSON.

{
  "id" : "1",
  "f_name" : "Adam",
  "l_name" : "Smith",
  "skills" : [
    "web development",
    "ux design",
    "data science"
  ],
  "team": "engineering"
}

Nesting like this can greatly simplify data storage and make data more easily digestible and traversible by an app. Unlike data stored in rows and columns, JSON can be structured to be infinitely deep. Objects can be nested inside objects, nested inside objects, etc..

Relational Database Structure

A similar dataset to the above might look like the following in a relational data schema:

employee [table]

  | id  | f_name    | l_name    | team        |
  ---------------------------------------------
  | 1   | Adam      | Smith     | engineering |

skill [table]

  | id    | name            |
  ---------------------------
  | 1     | web development |
  | 2     | ux design       |
  | 3     | data science    |

employee_skill [table]

  | id    | employee_id (fk)  | skill_id (fk) |
  ---------------------------------------------
  | 1     | 1                 | 1             |
  | 2     | 1                 | 2             |
  | 3     | 1                 | 3             |

In this case, to define the relationships between skills and employees we’re forced to use three tables, each with a rigid structure. The cost-benefit of JSON is evident, especially if data storage requirements ever change. Imagine the cost of maintaining 3 tables versus one flexible JSON object. Not all data is suited for JSON. For those who value maintainability and flexibility over rigid schemas, it’s a fantastic alternative—one increasing greatly in popularity.

Store Analytics Data

2013-12-09T00:00:00+00:00

JSON is a attractive option for setting up a custom analytics data store. The flexibility of JSON allows for website owners flexibly store data and get creative in changing tracked data over— all without worring about changing a database schema.

Here’s an example of what an object containing analytics data might look like:

{
  "_id":"0e494339-c94e-4834-93e6-8f0896c5346c",
  "_timestamp":"1386697259630",
  "_uid":"843f8e4f888de5b9",
  "_url":"http://www.mysite.com",
  "_referrer":"",
  "_category":"campaign",
  "_action":"share",
  "_browser":{
    "pdf":"1",
    "qt":"1",
    "realp":"0",
    "wma":"0",
    "dir":"0",
    "fla":"1",
    "gears":"0",
    "ag":"0",
    "java":"1",
    "res":"1440x900",
    "cd":"24",
    "cookie":"1"
  },
  "medium":"twitter",
  "campaign_id":"1",
  "product_id":"2",
  "other_field": "anything"
}

Notice some fields are prefixed with an underscore— these denote ‘default’ fields while fields without an underscore are considered ‘custom’ fields. This allows as to create extend our JSON objects, while still providing the bare minimum defaults that would be used in an analytics application. Say for example, in one month of implementing analytics tracking, business requirements change and now it’s important to track a new field ‘widget_type’. Without making a change to a database schema (common with relational databases), we can add the ‘widget_type’ field to analytics object and save.

Over time as tracking requirements broaden, the size (and number of fields) in your analytics objects scales infinitely to meet. When these objects are stored with a great DBAAS (DataBase As A Service) like a(href=”http://cloudant.com”) cloudant.com data can be easily mined for interesting patterns and returned to a dashboard for further visualization. Many web-based data visualization libraries use JSON natively, so starting in this format will be an additional time-saver.

Create a Universally-Readable Dictionary

2013-06-05T00:00:00+00:00

You ever need to create a dictionary?

Of course you do! Heck, I do it all the time!

Oh, stop looking at me like that. I don’t just mean language dictionaries! Address books, blogrolls, bibliographies, calendar events grouped by date… anywhere you have a list of words/phrases/terms/names/etc. and their corresponding definitions/explanations/details/etc., you’ve got a dictionary.

For example, suppose you wanted to create a list of tourist attractions in your favorite city:

Cerro San Cristóbal: A really big hill on the north side of town.
La Vega:             Awesome place to buy veggies.
Patio Bellavista:    Great nightlife and dining.

I’m going to go ahead and take the liberty of assuming that your favorite city is Santiago de Chile, but if this is completely unacceptable to you, feel free to follow along with your own list.

Not too shabby. Now, let’s tweak it a little bit by putting everything in quotes:

"Cerro San Cristóbal": "A really big hill on the north side of Santiago."
"La Vega":             "Awesome place to buy veggies."
"Patio Bellavista":    "Great nightlife and dining."

And just so that it’s clear where each entry in the list ends, we’ll add a comma at the end:

"Cerro San Cristóbal": "A really big hill on the north side of Santiago.",
"La Vega":             "Awesome place to buy veggies.",
"Patio Bellavista":    "Great nightlife and dining."

And for good measure, let’s decorate it with some curly braces because they’re just so goshdarned pretty:

{
  "Cerro San Cristóbal": "A really big hill on the north side of Santiago.",
  "La Vega":             "Awesome place to buy veggies.",
  "Patio Bellavista":    "Great nightlife and dining."
}

Well, would you look at that — we now have ourselves a properly-formatted JSON object! Not only is it still perfectly readable by humans, but you can now feed it into a script in just about any language.

And since most JSON readers don’t mind a little whitespace, you can make it even prettier:

{
  "Cerro San Cristóbal":
    "A really big hill on the north side of Santiago.",

  "La Vega":
    "Awesome place to buy veggies.",

  "Patio Bellavista":
    "Great nightlife and dining."
}

With a little bit of JSON, you can easily create attractive definition lists that are readable both by humans and computers!

Keep Track of Progress

2013-05-28T00:00:00+00:00

Let’s pretend that you are tasked with writing a one-off script to process a massive amount of backlogged data (a few of you might not have to pretend very hard). Because this script is ultimately going to be run once and then discarded, it would be a waste to spend lots of time building error handling routines and making the process super robust — it would be far less expensive just to expect failure and come up with an efficient way to deal with it.

And if there’s one thing you can count on, it’s failure. Servers will go offline, files will disappear, hamsters will chew through the power cables… one way or another, you’re going to run into a situation where a script or job that you’ve written will not be able to complete its task successfully.

And then what?

Well, you’ve got two options:

Clear out all the partially-processed data (assuming that’s even possible!), run the job again and hope extra hard that it works this time!
Periodically save your progress to a file so that your program knows exactly where to leave off in the event of a crash.

I don’t know about you, but I am rather partial to option #2.

For the purposes of this example, let’s say that you manage a website with a huge number of hosted image files (cc-by-sa, of course). One day, you noticed that other website owners are using your images without properly crediting your site. I know that barely ever happens in real life, but bear with me here. p So you’ve gotta write a script that does two things:

Submit each photo to a reverse image search API to locate unauthorized uses of the image and log the offending websites to a file for later follow-up.
Apply a watermark to each image so that future content copiers will attribute the images correctly whether they want to or not.

Step 1 could potentially take awhile, and there are a lot of opportunities for something to get screwed up somewhere along the line. Network outages, connection timeouts, the remote server sends back a 503 — there are a lot of ways this process could fail.

Even the watermarking process could go boom. A corrupted or oddly-formatted image might cause the image processor to crash.

Since you can’t spend hours and hours making your script fail-proof, you’ll have to find a way to keep track of your script’s progress so that in the event that something does break, the program can recover gracefully (and something will break – usually right after you go home for the evening, wasting an entire night’s worth of processing time).

JSON to the rescue! Yeah, I bet you were wondering when I’d get to the point already.

Imagine you started off with a status.json file that looked something like this:

{
  "img_1856322": {
    "search":     false,
    "watermark":  false
  },
  "img_1856323": {
    "search":     false,
    "watermark":  false
  },
  ... and so on ...
}

How this file was generated is outside the scope of this article, but given that you’ve made it this far, I bet you’ve already thought of at least 3 devilishly clever ways to do it.

When your script starts up, it reads the JSON object from the status file and starts traversing it, looking for tasks that haven’t been completed yet. As it finishes each step, it updates the object with the results (and don’t forget to write the JSON back to status.json each time it is updated so that you don’t lose your status in the event that the entire script gets crash-y!).

After awhile, status.json starts to show signs of life (explanatory comments added):

{
  "img_1856322": {
    "search":     [],   // Oh good; nobody's using this image!  It's mine!  All mine!!
    "watermark":  true  // Watermark completed successfully (:
  },
  "img_1856323": {
    "search":     ["http://www.istealimages.com/buy_my_poster/totally_legit.jpg"],  // Somebody is abusing our image!  Release the hounds!
    "watermark":  ["DivideByZeroError", "Unexpected divide by zero in region 42."]  // Oops; something went wrong during the watermarking!  Wait... *unexpected* divide by zero?
  }
  ... you get the idea ...
}

Notice something else cool about status.json? It doubles as a log file once the script is finished running! Not only do you have a lean placemarker file for your script, but it’s also in a format that’s easy for a human to scan through.

For really complex jobs or periodic tasks, you will probably find that it is worth the time to integrate a fully-featured job manager and spend the extra effort tuning your script for robustness. But when you have a one-off task to crunch through, consider using a JSON-formatted status file so that both you and your script can keep a handle on things.

Get More Bang for Your Relational Buck

2013-05-21T00:00:00+00:00

From time to time, your data models might suffer from field creep — you have to keep adding more and more fields to your models to work around edge cases and unique business requirements.

In the world of relational databases, this usually manifests either as additional fields tacked onto an existing table, or a separate “detail” table with a one-to-one relation to its corresponding source model — and these are just the least complicated approaches; there are far more complex ways to address the situation!

One approach to addressing the need for ever-more-specific-use-case fields: add more (increasingly ridiculously-named) fields to the table.

An alternate approach: move all of those pesky “detail” fields into a separate table that you can hide away in the closet whenever company comes over.

In addition to cluttering up your ERD, you are also leveraging the power (and overhead!) of your relational database engine for things that don’t actually need it.

Your pet store application might never need to filter a select query by userstory183274_marker value, but thanks to user story 183274, you still have to store that information with each pet.

Perhaps there’s another approach, one that is more scalable and doesn’t clutter up your database tables with (almost) useless fields… and yet still makes this custom information accessible to your application.

Well, as it happens, there is! Combine all of those extra “detail” fields into a single detail field that uses – you guessed it – JSON to store key/value pairs!

Much easier on the eyes!

Let’s peek at some values in our newly JSON-ified Pet table:

pet_id	owner_id	species_id	name	detail
1	1	1	‘Bowser’	`{"collar_manufacturer": "PetProtector", "rabies_flag": true}`
2	1	2	‘Oliver’	`{"has_name_tag": false, "music_preference": "Light Jazz"}`
3	2	1	‘Marcus’	`{"userstory183274_marker": "FILENOTFOUND"}`

Notice that in the time it took to draft up this table, we added a new feature: Musical Preference. Oliver likes Light Jazz.

Some of the benefits of storing “extra” data about your models this way:

You can add additional properties without having to alter your database schema.
Keeps your database schema tidy; only “essential” fields show up in your tables.

There are a few costs to this approach that you should be aware of, however:

It requires additional application logic to encode/decode the JSON in the detail field. This has implications both for performance and development time.
These fields are not indexable! If you need to search/filter by a property in a detail field, you will need to move it to its own column in the database table or use a system such as Lucene to index and search that value.
Extracting data from a detail field is an all-or-nothing operation; you have to pull the entire JSON string from the database and decode it in your application to find a specific property. This is usually not an issue for modern ORMs, since all columns are usually automatically pulled in every time they fetch a record from the database.

For storing one-off properties and flag values that you only need at the application level (i.e., you do not need to index/filter/search these values), think about whether you can store these values in a single JSON-formatted string instead of bloating your tables with extra fields.

And if you find that you’re using this feature a lot in your relational-database-powered application, you might want to consider whether a NoSQL solution such as CouchDB is a better fit for some or all of your data!

Write a Better Config File

2013-05-20T00:00:00+00:00

Anyone who’s been writing applications for awhile has run into the problem of making the application’s behavior configurable in different operating environments. From DSNs to administrator email addresses, it’s important to have a set of configuration values that live outside the codebase.

But how to store these values in a format that a computer can easily read and write?

A lot of solutions have been tried over the years, including INI, XML and YAML. Each of these formats has its strengths, but they all lack the combination of power and simplicity that JSON offers.

Consider a configuration file that stores database connection strings for different operating modes. Let’s start by seeing how you might write it with INI syntax:

[prod]
sql_username   = dbuser
sql_password   = dbpass
sql_hostname   = 192.168.113.172
sql_portnum    = 3306
sql_database   = app_database
redis_hostname = 192.168.113.173
redis_portnum  = 6379

[test]
sql_username   = dbuser
sql_password   = dbpass
sql_hostname   = 192.168.113.172
sql_portnum    = 3306
sql_database   = test_app_database
redis_hostname = 192.168.113.175
redis_portnum  = 6379

Well, it gets the job done, but it’s kind of… verbose. Plus, if that config file gets long enough, it will get really difficult to separate the different sections (prod, test, etc.).

What about an XML config file?

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE configurations SYSTEM "path/to/config.dtd">
<configurations>
  <configuration mode="prod">
    <option key="sql">
      <value key="username" type="string">dbuser</value>
      <value key="password" type="string">dbpass</value>
      ...
    </option>
    <option key="redis">
      <value key="hostname" type="inet_addr">192.168.113.173</value>
      <value key="portnum" type="integer">6379</value>
    </option>
  </configuration>
  <configuration mode="test">
  ...
  </configuration>
</configurations>

Yuck — and I thought INI was verbose! I didn’t even want to type the entire thing out, it got so huge! And by the way, good luck trying to store array values!

How about YAML?

---
prod:
  sql:
    username: dbuser
    password: dbpass
    ...
  redis:
    hostname:  192.168.113.173
    portnum:   6379

test:
  sql:
    username: dbuser
    password: dbpass
    ...
  redis:
    hostname:  192.168.113.175
    portnum:   6379

Not bad. Definitely easy for a human to read, and there are libraries in practically every programming language to read and write YAML files. But I’ll share with you a little secret: YAML is JSON-compatible!

That’s right; the above configuration file could also be written like this:

---
prod:
  sql:   {"username": "dbuser", "password": "dbpass", ...}
  redis: {"hostname": "192.168.113.173", "portnum": 6379}
test:
  sql:   {"username": "dbuser", "password": "dbpass", ...}
  redis: {"hostname": "192.168.113.175", "portnum": 6379}
p Well, if you're going to go and use a configuration file format that's compatible with JSON... why not use JSON?
pre.
{
  "prod": {
    "sql": {
      "username": "dbuser",
      "password": "dbpass",
      ...
    },
    "redis": {
      "hostname": "192.168.113.173",
      "portnum":  6379
    }
  }, 
  "test": {
    ...
  }
}

Not only do you get an easy to read syntax (for both humans and computers), but you also get the advantage of being able to explicitly supply a type for your configuration values.

Try to set a configuration value to null in an INI or YAML file (credit where it’s due, at least XML can handle this… if you don’t mind typing a dozen extra characters!).

What about true or false? In JSON, this is just part of the syntax:

{
  "prod": {
    "use_caching": true
  },
  "test": {
    "use_caching": false
  }
}

And with JSON libraries available in nearly every programming language (or supported natively if you are developing a Node.js app!), it’s incredibly easy to integrate a JSON configuration into your application!

Keep Function Parameters Tidy

2013-05-19T00:00:00+00:00

We’ve all been there before: You finished putting together an awesome class or function whose behavior can be configured down to the smallest degree, and now to wire up all the different configuration values:

function jsonapi(url, data, pre_execute_hook, success_hook, failure_hook, error_hook, post_execute_hook, async, method, jsonp) {
  ...
}

What a mess. Can you imagine trying to call that monstrosity?

jsonapi('http://www.example.com/rest/doSomethingAwesome', {"subscribe": ["peter", "henrietta", "xavier"]}, null, mySuccessHandler, myFailureHandler, myErrorHandler, null, null, null, true);

At least you have some job security — nobody is going to want to maintain that thing!

However, there’s a better way to organize your function parameters using JSON:

function jsonapi(options) {
  // Merge options with default values.
  options = $.extend(
    {
      // Standard Options
      'url':          '',
      // Hooks
      'pre_execute':  null,
      'success':      null,
      'failure':      null,
      'error':        null,
      'post_execute': null,
      // Advanced Options
      'async':        true,
      'method':       'post',
      'jsonp':        null,
      'data':         null
    },
    (options || {})
  );
}

Note that we are using the extend() function from the jQuery library to merge values in the options parameter.

When you are invoking the function, pass a JSON-encoded object as the value of the options parameter:

jsonapi({
  "url":      'http://www.example.com/rest/doSomethingAwesome',
  "data":     {"subscribe": ["peter", "henrietta", "xavier"]},
  "success":  mySuccessHandler,
  "failure":  myFailureHandler,
  "error":    myErrorHandler, 
  "jsonp":    true
});

You might have noticed several advantages to this method:

The values you are passing at invocation time are self-documenting — even without looking at the function signature, you can tell which option each value corresponds to.
You can omit any options that should use the default value — in the above example, the we did not have to pass a null value to the pre_execute, post_execute, method and async options; the function automatically uses default values if they are omitted from the JSON object passed to it.
Individual options can be documented in the function body itself. p One thing to be careful about though, is that the different options are no longer part of the function’s signature, so IDE tooltips and auto-completion won’t work. Make sure you document well your functions and the options they expect if you are using this technique!

Communicate with Remote Servers

2013-05-18T00:00:00+00:00

When you need to send data back and forth with a RESTful webservice or other backend server, you need a way to structure the data that you send and receive.

In a previous age, ajax requests would send key-value pairs to webservices using query parameters or as form-encoded values in the body of a POST request.

However, this gets really bulky when you need to send arrays and nested objects. Imagine trying to transmit these data via URL parameters:

{
  "subscribe": [
    "peter",
    "henrietta",
    "xavier"
  ]
}

The resulting URL might look something like this:

http://www.example.com/services/subscribe?subscribe[]=peter&subscribe[]=henrietta&subscribe[]=xavier

Yuck.

However, ajax requests are perfectly capable of sending JSON-encoded payloads within the body of a POST request, which is much cleaner. Here is an example of how to send a JSON-encoded POST body with the jQuery library:

$.ajax({
  "contentType": "application/json",
  "data": '{"subscribe": ["peter", "henrietta", "xavier"]}',
  ...
});

Note that you have to send the JSON object as a string, since otherwise jQuery will invoke the object’s toString() method, and you’ll end up sending “[object Object]”, which is not particularly helpful!

Just about every server-side language has a JSON library, so decoding the incoming request payload on the server side is trivial. Here are some resources for common server-side languages:

C#
Java
PHP
Python
Ruby

Don’t forget to have the remote service send back its response in JSON, too!

Keep Functions Tidy

2013-05-17T00:00:00+00:00

When you want to keep your functions out of the global namespace, use JSON. A common development pattern for this is placing functions inside an object looks like this:

var nameSpace = {
  "myFunc": function(x, y){
    return x + y;
  },
  "otherFunc": function(x, y, z){
    return this.myFunc(x, y) * z;
  }
}

Now you can access your functions the same way you access any other object property. In this case, the functions are referred to as “methods”.

console.log( nameSpace.myFunc(1, 2) );
// returns 3

Another advantage you have of declaring functions in an object literal is gaining access to the this variable within each method. In the example above, this refers to nameSpace object. It can be referred to easily in this manner without declaring any functions in the global namespace. Handy indeed.

Store Global State Variables

2013-05-16T00:00:00+00:00

Ever build a JavaScript app and find there are certain variables you need to access in various places throughout the code? If you’re doing it right, you’ve smartly designed your app in a modular, decoupled fashion - yup, check. One way of using variables across these decoupled components is to pass them from one function to another, effectively pushing them down a daisy-chain as needed. This is not always the best way because said variables are only accessible at the time when a function is fired. An alternative to this approach is to use JSON to store your variables in a global object.

var globalVars = {
  "miliseconds": "5000",
  "turtleFarts": "1.3"
  "laserBeams": 3
}

var getTurtleFartsPerSecond = function(){
  var tfps = globalvars.turtleFarts / (global.miliseconds / 1000)
  return tfps;
}

var getPiLaserBeamsPerSecond = function(){
  var PiL = (Math.PI * global.laserBeams) / (global.miliseconds / 1000)
}

Visualize JSON-formatted Data

2013-05-15T00:00:00+00:00

Can you remember the last time you came across a data visualization library that didn’t use JSON as the primary input? If you have data in JSON format data, whether it’s coming from a document-oriented data store (i.e. CouchDB, MongoDB) or a hand-coded JSON object, you’ll be able to leverage it quickly with a web-based visualization library. This usually requires transforming the data slightly to get it in the exact structure required by the visualization library.

JSON is the most popular data interchange format on the web and it has been embraced by the creators of the most popular data visualization libraries on the web, namely Highcharts and D3. There are so many different styles and dimensionalities possible with visualization that table-oriented data is no longer enough to reach full potential. JSON is flexible enough to support many thousands of combinations of data structures needed by today’s visualization and is becoming the universal format of choice.

var myDataSet = [
  {
    "label": "week one",
    "goalReached": true,
    "avgTemp": "84.3"
    "miles": {
      "mon": "12",
      "tues": "0",
      "wed": "15",
      "thu": "0", 
      "fri": "21" 
    } 
  },
  {...},
  {...}
]

Make the Perfect JSON Schema

2013-05-14T00:00:00+00:00

Schemas in JSON are unlimited in breadth and depth. With support for nested arrays and objects, JSON can be used to create flexible schemas which help store and transport data in a way that bests suits the needs of an application. When the architecture of an application changes (as do the data transport and data storage needs), it’s convenient to use a flexible format that isn’t restrained by a two-dimensional, table-oriented paradigm.

Data can be complex, ugly, multi-dimensional and just plain weird. For this, JSON natively supports more complex structures like arrays-of-arrays and objects-of-objects. Creating a schema with JSON (and storing your data in JSON) is often a great choice in order to future-proof your application to inevitable changes - you’ll be able to adapt quickly and reduce the odds of having to re-architect you system when changes happen.

var wickedSchema = {
  "nesty_o": {
    objectInAnObject: "sure"
  },
  "nesty_a": [
    ["three levels deep", "hells yeah"],
    "a string here",
    {"objectInAnArray": "yup"}
  ],
  "someString": "whoah buddy"
  "aNumber": "3.14"
}