Doing the same work twice is never a good thing. Knowing that, a pattern called “Memoization” can help you avoid this. It’s about building functions that remember their previous outputs/return values.

Let’s pretend you’ve written a function that takes a number as an argument and multiplies it with, say, 2.5. Not exactly heavy computational work, but for the sake of clearness…

var multiplierFunction( myNumber ) {
    return myNumber * 2.5;
}

If you call the function 10 times, it will have to do the computation 10 times. In cases where there’s some more effort inside the function, this can be a waste of performance.

To reimplement it using memoization, you just need to provide a plain JavaScript object that remembers previous results. Here, we call it “memo” and attach it right to the function:

multiplierFunction = function( myNumber ){
    if ( typeof multiplierFunction.memo[myNumber] != "undefined" ){
         return multiplierFunction.memo[myNumber];
    }
    // the following code will only be executed if necessary
    // i.e. if the same calculation wasn't done before
    multiplierFunction.memo[myNumber] = myNumber * 2.5;
    return multiplierFunction.memo[myNumber];
}
multiplierFunction.memo = {};

Inspecting objects at runtime is what’s called “reflection”. Maybe you want to know – at runtime – what methods an object has or what type of object it is. You’ve got a couple of tools at hand to do this in JavaScript:

typeof & constructor

Before you read on, you should be familiar with both the “typeof” keyword and the “constructor” property. If you’re not (yet) familiar, you can get yourself up to speed by reading my previous post about type checking.

for…in

With for…in you can iterate over the properties of an object. So if you want to know which methods an object has, you can write something like this:

for ( prop in myObject ){
    if (typeof myObject[prop] == 'function') {
        // ...that's a function
    }
}

hasOwnProperty

Iterating through an object’s property is fine – unless you need to know if it’s exactly _this_ object, and not one of its parents in the inheritance hiearchy, that has this property.
To find out just that, you can use “hasOwnProperty” which doesn’t look up in the prototype-chain, but only in the very object you’re calling the method upon:

// true, if a property named "myMethod" exists in the object itself
myObject.hasOwnProperty('myMethod');

JavaScript can be a very dynamic language. To prove this, today we’ll discuss two techniques: dynamic code generation in general and “branching” (a special form).

Dynamic method generation

JavaScript allows you to add, change, or remove functions dynamically at runtime. Since functions are just objects in JavaScript (see my previous post on functions), you could just add a new one like this:

var someVariable = "Dynamic";
this["my"+ someVariable +"Function"] = function(){
    // your code
}

As soon as these lines get executed, you have a function called “myDynamicFunction” at hand.

A little more complex (and more useful) example comes from John Resig: he shows a way to create “getter” and “setter” methods for the properties of an object. In this example, a “User” object, that expects an object with some properties upon initialization. For these properties, we then generate setters and getters:

function User(properties ) {
  self = this;
  // iterate through the properties of the object
  for ( var property in properties ) {
    (function(property){
       // create a new getter for the property
       self["get_" + property] = function() {
         return properties[property];
       };
       // create a new setter for the property
       self["set_" + property] = function(val) {
         properties[property] = val;
         return self;
       };
    })(property);
  }
}

EDIT: thanks to “tester’s” comment with a correction of the above code!

Branching

Branching can be used to override an existing function with an optimized version on first run. A good example scenario is writing cross-browser code.
Imagine you have to write a function that does one thing when run in one browser, and totally different things in another one.

function xyz(){
   if ( a == b ){
      // do one thing
   }else{
      // do another thing
   }
}

You would have the (in this example case admittedly small…) performance hit of at least running the condition code to distinguish between the two browsers. If the condition is quite expensive to run, or if the code will be run very very often (so that even a minimal performance improvement is desired), branching comes in handy.
Instead of checking the condition each time, it is only checked one on the first call of the function. Then, the function is rewritten – without the condition:

function xyz(){
   if ( a == b ){
      // override the function with the code for case A!
      xyz = function() { ...code for this case... };
   }else{
      // override the function with the code for case B!
      xyz = function() { ...code for that case... };
   }
}

From the second time on, when xyz is called, there is no condition – just plain optimized code. Of course, this means that the condition should not change during runtime; it should be always the same, because it won’t get checked a second time.

Actually, I planned to write an article about “Reflow” – an important performance-relevant topic in every highly interactive JavaScript application.
But, as I was doing research for the article, I noticed that there are already a handful of very good articles and resources out there. So, instead of re-describing the wheel, I highly recommend reading through these:

• http://www.mozilla.org/newlayout/doc/reflow.html
• http://dev.opera.com/articles/view/efficient-javascript/?page=3#reflow
• http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/

Maintaining and keeping code clean is always a challenge. And JavaScript is not different here.

In complex applications, JavaScript combines a great deal of application logic with classic GUI concerns. Therefore, temptations are high to put things like labels/texts into code (i.e. hard-coding the values). But already the term “hard-coded” should let you think twice.

A better solution is to keep things like

• labels / texts
• URLs
• configurable values

out of your functions.

Using a single “configuration” object in JavaScript is a simple and comfortable solution to this problem:

MyNamespace.configuration = {
    uris: {
        data_loading_url: 'dummy_data.json',
        details_url: '/projects/###ID###/show'
    },
    labels : {
        date_button: 'Go to date',
    }
}

Using those prepared values in code is then as easy as pie:

var link_element = '<a href="' + MyNamespace.configuration.uris.data_loading_url + '">';
link_element += MyNamespace.configuration.labels.date_button;
link_element += '</a>';

This makes changing those values easy and safe – and separates changeable content (configuration values) from your logic/code.

In currently popular versions of JavaScript, there’s no native concept of namspaces, like in C#, Java and Co.
But namespaces are important when it comes to larger applications and/or using third party code. You risk to have conflicts with other code (being it your own code or third party code) that is named the same. Unexpected behaviour, to say it politely, can be the result (apart from polluting the global namespace with a lot of variables is just not very nice…).
So we know we need a way to simulate namespaces in JavaScript, too.

It proves to be as simple as creating one global object that hosts all your code:

var FOCUS = {};
FOCUS.firstFunction = function(){
   // your code, not polluting the global namespace...
}

There might be situations when you don’t know if you’ve already created a certain namespace. You can check it (and create it, if it doesn’t exist, yet) easily:

if ( typeof FOCUS == 'undefined' ) var FOCUS = {};

Since JavaScript currently is a dynamically typed language, the topic of type checking is quite interesting. In certain situations it’s rather important to know of which type the object at hand really is.

Here, we have some dummy objects that we want to type-check:

var num = 12;
var string = "Hello World";
var array = [1,2,3];
var object = { firstProp: 1, secondProp: 2 };
function Car(){};
var car = new Car();

Let’s look at two different ways to check the type of an object.

typeof

With the help of the typeof keyword, you have one possibility to check an object’s type. An example usage could look like this:

if ( typeof num == "number" ) ... // true
if ( typeof array == "array") ... // false, because "object" is returned
if ( typeof car == "Car" ) ... // false, because "object" is returned

The typeof way works nicely with most object types. But unfortunately, it leaves a little uncertainty when dealing with types like Array or your own types (like “Car” in our dummy examples). That’s because typeof only returns the not so helpful “object” in those cases. So let’s look at another way…

constructor

Every JavaScript object has a property called “constructor” – which proves to be helpful in our case:

if ( car.constructor == Car ) ... // true
if ( array.constructor == Array ) ... // true

The constructor-variant has the advantage of returning a reference to the function that was used when creating the object in question – not just “object”. Since a reference is returned, you have to remember not to use quotation marks (in contrast to the typeof variant, where a string is returned).

Closures are a vital part of JavaScript’s dynamic nature. Without it, a lot of things would work totally different. Because of this significance, it’s important to thoroughly understand closures.

So, what _is_ a closure, really?

• A closure simply is a function inside of another function (an inner function, if you will)…
• …that has access to the context of its outer/enclosing function…
• [now it gets interesting!] …even if the outer function has already terminated.

Okay, let’s have an example:

var myFunction = function(text){
     setTimeout( function(){
         alert(text);
     }, 1000);
}

Here, the case is quite clear: when the inner function is called through the timeout, the outer function (”myFunction”) has long terminated (about 1 sec. ago). Still, the inner function has access to the variables of its parent function (the variable “text”, in this case).

Some more examples should make the use and importance of closures a little clearer:

(function(){})();

Used in many modern AJAX libraries, this construct can be quite puzzling on first sight. So let’s deconstruct it outside-in, to see what’s it all about.
The (…)() construct is used to hide the contained code from the outside world (and scope). Try this example for yourself:

function testFunc(){};
(function test2Func(){});
console.log(window.testFunc);
console.log(window.test2Func);

The first one, testFunc, is visible to the outside world (window.x), the second is hidden from it. So (…)() can be used to avoid polluting the global namespace.

The anonymous function inside of the parentheses is used to create and execute the desired code in one go. Additionally, we have access to all outside variables – because a function always has access to it’s surrounding context.

private variables

As you probably know, the JavaScript language currently doesn’t have the concept of public/private/protected members. But with closures, we can simulate this system:

function publicPrivate(){
     var privateProp = "This one is private";
     var privateFunc = function(){ console.log("From private func:", privateProp); };
     privateFunc();
     return {
        publicProp: "This one is public"
     }
}
var myObj = new publicPrivate();
console.log("From outside:", myObj.publicProp);
console.log("From outside:", myObj.privateProp);

The last console.log will return undefined in Firebug, because privateProp can’t be accessed from outside. The first one, from inside our publicPrivate function, will return “This is private” because we’re calling our private member from inside.

PREFACE: This is the first post in a series of posts about JavaScript. There’ll be roughly one post per week in the next couple of weeks (don’t ask me, yet, how many weeks I’m going to hang in there – a couple, at least! .
The goal is to give a thorough overview of some important core aspects of the language – ranging from building blocks like closures to best practices like unit testing.
Honor to whom honor is due – I’ve not invented these concepts and best practices but learned them from some of the best – most notably folks like John Resig or Douglas Crockford.

The first post is about the concepts of “functions” in JavaScript.

NOTE: In a lot of examples, you will see the expression “console.log(…)”. This causes Firebug to output something on its console. So please have the Firebug plugin for Mozilla Firefox ready when you’re playing with the code.

==============

Functions are a core part of JavaScript. Admittedly, functions are a core part of almost every language. But since JavaScript doesn’t have the classic implementation of classes (more on that in a later post), functions become even more important.

First of all it’s important to know that functions are indeed objects in JavaScript. Because they’re objects, quite a few very JavaScriptish things are possible – that might not be common in other languages.

• Functions can be stored in variables

  var myFunction = function(){
      alert("Hello world");
  };

• Functions can return functions

  var my2ndFunction = function(){
      return myFunction;
  };

• Functions can be arguments to other functions

  var alertThroughFunctionArg = function(arg){
      arg();
  };
  var argFunction = function(){
      alert("Number 4");
  };
  alertThroughFunctionArg(argFunction);
  // ===> "Number 4"

• Functions can have properties
  This might seem a little strange. A function that has properties?? Yes, you’re right. If you remember that a function is „just“ an object, it sounds reasonable that a function can have properties.

  function calledFunction(){
      calledFunction.called += 1;
  };
  calledFunction.called = 0;
  
  calledFunction();
  calledFunction();
  calledFunction();
  console.log(calledFunction.called);
  // ===> 3

• Functions have a prototype attribute (more on that in a later post)

„arguments“ variable

Every function has a variable called „arguments“.  It’s a array-like collection of all the arguments the function has received. „Array-like“ because you can access its items, but not manipulate it. It can be used to implement what’s known as „function overloading“ in other languages.

„length“ property

There’s another freeby regarding functions: the length property, which also every function has. It contains the number of expected (defined arguments in the function signature -  not the number of really passed arguments when called!).

function lengthFunction(a, b, c){
    console.log(lengthFunction.length);
};

Calling lengthFunction would show „3“ in Firebug.

return value

Every function has a return value. Whether you’re explicitly stating „return“ or not. If you’re not returning an explicit value, „undefined“ is returned. This is similar to what is delivered to the function body, if a parameter wasn’t provided at all at call time – „undefined“.

scope

Unlike other C-syntaxed languages, JavaScript has no „block-scope“. Variables are visible inside the function where they’re defined. If you define them inside of a block, like an if-statement, they continue to be visible even if the block is left. So, JavaScript only cares about function-scope, there’s no block-scope.