When it comes to organizing your object literals, there are multiple approaches you can take
Object Literals are a very useful feature of JavaScript. They allow you to easily build structures of data or functionality (or both mixed together), without too much fuss and drama. The syntax is simple and they make it easy to name-space your code. But, when your object literals start to grow in size, they can become a bit difficult to manage. And, it can sometimes make your code harder to follow.
In the next few examples, I will cover a couple of alternate ways to organize your JavaScript Object Literals. This can make your code easier to manage and understand.
Example # 1
1 2 3 4 5 6 7 8 9 10 11 |
var mathFuncs = { add: function(a,b){ return a + b; }, subtract: function(a,b){ return a - b; }, multiply: function(a,b){ return a * b; } } |
In Example # 1, we have an object literal that has been assigned to the variable “mathFuncs”. This object has three members: “add”, “subtract” and “multiply”. Each is a function. This is not too bad, but what if each function was tens or even hundreds of lines of code? The entire “mathFuncs” object itself would grow to become thousands of lines long. This can become unwieldy. Also, if while making edits, one semicolon gets knocked out of place, the entire object is likely to become defective, which will pretty much kill the script.
Example # 2
1 2 3 4 5 6 7 8 9 10 11 12 13 |
mathFuncs = {}; mathFuncs.add = function(a,b){ return a + b; }; mathFuncs.subtract = function(a,b){ return a - b; }; mathFuncs.multiply = function(a,b){ return a * b; } |
In Example # 2, “mathFuncs” is initially one line of code: an empty object. We then extend the object by adding more properties. In this case, the three properties we add are “add”, “subtract” and “multiply”. Functionally, there is no difference between this approach and Example # 2. These anonymous functions will perform no differently. What is different is that the code is a little bit easier to follow. First you see that “mathFuncs” is an empty object, and then we add properties to it. These properties are all functions, so they should be referred to as “methods”. Also, if you have a bug in one of the anonymous functions, it is less likely to break the entire script, and could be easier to track down.
Since these functions are very small, there is yet another level of optimization that we can apply:
Example # 3
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
mathFuncs = {}; mathFuncs.add = function(a,b){return a + b}; mathFuncs.subtract = function(a,b){ return a - b}; mathFuncs.multiply = function(a,b){return a * b}; mathFuncs.bigFunc1 = function(){ //this is a much bigger function //with multiple lines of code //so let’s put it at the bottom }; mathFuncs.bigFunc2 = function(){ //this is a much bigger function //with multiple lines of code //so let’s put it at the bottom }; |
In Example # 3 we tightened up the first three functions because there is so little going on in them, so it’s no harm to make them all one line each. Again, it’s just easier for someone else to quickly read and understand. We added two new properties, both anonymous functions as well. Since these are bigger functions (let’s pretend they are each 50+ lines of code), we put them last so that they are a bit out of the way, and we only have to see all that implementation code if we care to.
This is all a matter of preference. From time to time, I think that not everyone realizes that there are options when it comes to object literals and how you choose to write them out. The approach taken in Example # 1 is fine, especially when the objects are small. But when you have many properties in your object, and those properties are anonymous functions that contain tens or hundreds of lines of code, it can make your logic hard for someone else to follow.
Summary
There are many ways to skin a cat, and as many ways to organize your JavaScript code. The purpose of this post was to offer a few suggestions that can make your object literals a little bit easier to read, especially for someone else who, in the future, might have to read, understand and then make changes to your code.